About squeak image compatibility (3.6/7/8)
ducasse at iam.unibe.ch
Sun Jan 8 21:08:21 UTC 2006
I really have the impression that you are right. May be we should
make a list of the code in the image that we want to keep.
I have the impression that we should finish fast 3.9 and then 4.0
should be the throw away party.
I was thinking about Etoy especially since now Etoy is developed in
Tweak and there is Etoy in 3.8.
For the rest, I agree. I do not think that MC really is the problem.
We learned and now this is working much better.
I especially think that you do not rewrite the file system every
version so such kind of breakage should happen one
or two times max over 10 years. This would give a lot of good energy.
>> So , who is in charge of Alice ?
>> And the all Games ?
>> And MorphicWrappers ?
>> And many , many orphans ? (today I answer to how load StarBrowser)
> No-one. And that's a big handicap these days. Because even if all the
> packages are maintained, the integration team has quite a task. But
> now they have the burden of keeping all the orphaned stuff in tact...
> I'm almost inclined to say "kick it out, if no-one wants to maintain
> it it's not worth keeping". This would force the issue, but would risk
> that some of the cool goodies are left to rot.
> These are currently two very important issues for the community to
> discuss and decide upon - compatibility and carrying old code around.
> Personally, I'm opposed to either one.
> <insert sound of Cees stepping on the soapbox>
> Squeak was supposed to be nimble, agile, a sort of heat-seaking
> missile that could track new ideas just as fast as you could come up
> with them.
> Current Squeak couldn't be much farther from that (as far as Squeak
> goes - obviously, there are development systems out there that are
> much, much farther from the goal but I won't drop the "J" word here).
> Doing work on 3.9a is as much fun as wading through quicksand.
> One reason is that we have handicapped ourselves by mandating that all
> packages become maintainable with MC. This is a necessary step to be
> able to become more distributed.
> However, the other big reason is because of fear. The exact same kind
> of fear, I think, that has gotten us beautiful products like C++ or
> (oh gosh, the "J" word) Java. Fear that being nimble and agile doesn't
> That's why we are carrying stuff around in the image instead of
> kicking it out, and that's why we all *know* that the whole I/O system
> sucks, and that we *know* how to do it better (Flow and the VW
> interface provide ample evidence that it can be done better, I think),
> but we are simply, as a community *afraid* of introducing breakage.
> We are simply afraid that if we introduce a new, better interface, we
> may break old code and this old code will be hard to repair. All other
> reasons, I feel, are just dragged into the arena of debate by their
> hairs in order to prevent us having to confess this very simple fact.
> We have the finest development tools in the world, and we're afraid to
> use them.
> Do you feel silly already? Good ;-).
> I say: old, unmaintained code should be ejected from the image. Kick
> Alice out. If no-one takes it up, that probably means that it is not
> important enough. Kick MVC out. Kick all the games out. Let'em be
> adopted or rot. Somehow, I think that this will serve as a
> self-selection of interesting code because I am quite sure that
> *someone* out there wil have enough interest in Alice to either step
> up and adopt the code, or - if it is an end-user - rally for support
> to have it maintained. Think voting with your feet...
> I say: compatibility is not a major goal. It's nice to have, but
> shouldn't become a burden. Because if we introduce major breakage (say
> by kicking out everything files and network, loading flow, and
> declaring that the next version of Squeak), you have two options:
> - Stick with the current version for the duration of your project
> (every single Squeak version ever created is still downloadable from
> Squeak.org - no-one is putting a Colt .45 to your head shouting that
> you must upgrade or die);
> - Swallow the 2-4 hours of time and upgrade.
> A well-factored project will have only minor impact if, say, the
> network layer API changes. If your code really suffers, it was time to
> refactor it anyway. Don't blame the maintainers of the files/network
> kernel for your bad code, and certainly don't put the burden of your
> bad code on their shoulders by opposing compatibility breakage if that
> results in a better Squeak...
> So. that's out :-). I have painted my arguments in black-and-white on
> purpose, because I really want this discussion going. I want to have
> some sort of simple policies around maintenance of Squeak, where I
> would propose "unmaintained packages are not included" and "backwards
> compatibility is not a major goal but compatibility changes should be
> well documented and well announced".
More information about the Squeak-dev