Tweak mainstream in Squeak

Andreas Raab andreas.raab at gmx.de
Mon Jul 10 22:56:21 UTC 2006


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?

Cheers,
   - Andreas



More information about the Squeak-dev mailing list