About squeak image compatibility (3.6/7/8)

Samir Saidani saidani at squeakfr.org
Sat Jan 7 21:35:49 UTC 2006


Hello,

I've recently noticed the arrival of the KeyedSet classes (Squeak
3.8), which break some codes I'm working on. So it is rather strange
because I thought that efforts was focused on reducing the size of the
image, on packaging and modularizing. Is there any real agreement
about the way squeak core is managed ? More precisely, I see three
options :

1. 3.6 > 3.7 > 3.8, which makes sense when the code is too young and
     must grow.

2. 3.6 | 3.7 | 3.8, which means that we add somewhere and remove
     elsewhere, and implies that packaged code is always endangered to
     be broken.

3. 3.6 < 3.7 < 3.8, which means that the modularizing plus packaging
process is on the way.

It seems that at least for 3.8 we are on the second track, is there
any plan to switch to the third track ? Staying on track 2 is really
painful for developers who work between three different images, a lot
of time must be spent to keep compatibility of the package and the
three version. When do we agree that 3.x and 3.x+1 must be compatible
? And first of all, do we agree that we must ensure compatibility
between two successive version one day ? I mean by compatible:

1. If code is added in 3.x+1, an equivalent packaged code is provided
   for 3.x (not the case for KeyedSet even if there is a KeyedSet
   class in an embryonic state in Collections-Misc, but maybe I missed
   the information of another package ??). Hey, I've just noticed that
   this statement seems to connect directly track 1 to track 3.

2. If code is removed in 3.x+1, an equivalent interface is provided in
   3.x and the old one are marked as deprecated.

3. If code is added or removed in 3.x+1 and breaks compatibility (for
   instance, removing deprecated methods), it should be mentionned
   explicitly, for the sake of coding :-)

4. If global compatibility can not be insured (track 2), it should be
   mentionned explicitly to developers into the image itself (to avoid
   digging endlessly into the mailing-list).

5. Probably something I missed which probably invalidate one or all
   the statement above...

Regards,
Samir



More information about the Squeak-dev mailing list