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