Lukas Renggli wrote:
 >> Honestly, Stef, if it isn't random then what is the strategy for these
 >> changes? Looking at the past Squeak versions, starting from 3.6 every
 >> version was just incompatible enough with previous versions such that it
 >> would break any serious user of the metaclass hierarchy (like Tweak). I
 >> think you will agree that it can't continue that way, that at some point
 >> we need to get back to what can be called a *stable* metaclass kernel
 >> with reliable APIs and when exactly will that point be reached?
 >
 >
 > To improve software, it is required to break backward compatibility.
 > Nobody is forcing you to move to a new version.
 >
 > 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.
 >
 > 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.

It's not quite that simple...

To improve software, it MAY be required to break backward compatibility. 
  But it should always be a conscious decision to do so.

In my opinion, in Squeak, it is an even bigger issue: although my 
software may not require the new features of 3.9, I dread the thought of 
having to go back and work in a 3.6 image.  Not only do I lose many of 
the development environment features I like, it's DIFFERENT.  Having to 
re-learn the intricacies and bugs of a new environment every time I need 
to fix a bug in my stable software just because someone decided to 
"improve software" is not efficient.

I'm not saying don't break compatibility, I'm just saying be aware every 
time that you are doing it.  And the thought that there be a relatively 
stable API for a core set of classes that doesn't change without some 
forethought is perfectly reasonable, in my opinion.  At least then, when 
compatibility is broken, detailed instructions could be provided on how 
to update your software in each case.

Julian