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
|