Andreas Raab wrote:
Lukas Renggli wrote:
To improve software, it is required to break backward compatibility. Nobody is forcing you to move to a new version.
For starters, let's get our basic assumptions right: This discussion isn't about people who do *not* want to move to new versions. It's about people who *do* want and what expectations they can have. Otherwise I'd agree with your statement.
If updates to the base-framework don't enhance anything in the development process of your software, it is unnecessary to update. If I were you, I would stick with 3.6. Still waters run deep.
Well, if you were me, you would *want* to update. But you would have noticed that things got so inconsistently broken at the metaclass level that unless there are major pay-offs, it simply isn't worth the effort. That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff - the m17n integration. That's why I then spent the time needed. For 3.9, from a Tweak POV there isn't that much interesting in there, so rather than going through the painful porting exercise yet again I'll probably spend my time on bootstrapping a stable (3.8-based) metaclass kernel which can be used in parallel to the 3.9 kernel. Which is not particularly nice but in the absence of any inclination towards stable APIs the only alternative that I can see.
I have some legacy Seaside applications in ancient 3.6 images that run just fine. They rarely change. They simply run fine. I won't port them to 3.9 and a recent version of Seaside. These applications don't require anything more as it is available in 3.6. However, for new applications I take 3.9, I love Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to keep up-to-date as long as it improves my productivity.
You're totally missing my point. Let's take one example from your list: ToolBuilder. Let's say you've got some work that uses it, would you really expect that in each new Squeak version you have to spend major effort to port your code to the latest ToolBuilder version? Or wouldn't you rather expect that there is a stable API that can be used and that may be extended over time, or even broken, but if it's broken that you may get some notice about it beforehand? Or, in particular when the changes get really fundamental, that instead of modifying ToolBuilder in-place you get the offer to use either ToolBuilder (working the way it always did) and whatever the brand-new framework of the day is?
I'm curious but is my position in this discussion really so outrageous?
it sounds right to me. I would want to update to the newest just for bug fixes alone. And, I wouldn't want any surprises. If something is broken, it should be easy to state that somewhere so people can have a look before upgrading.
brad