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
|