> Let me explain: In Debian I think they have "rules" describing when a
> package goes down into testing and when it finally goes into stable. For
> example, I think that a package needs a certain time in unstable without
> having any bugs reported against it and then it will automatically enter
> testing.

Actually, Debian doesn't move individual packages forward to stable --
it moves an entire distribution forward.  That is, "woody" as a whole
goes from unstable to testing to stable, not "gcc-3.0".

There's a deep reason for this, and I think the Debian folks got it
right, at least for Unix.  The depends/suggests/conflicts/etc.
relationships don't capture all of the interactions between packages. 
There are lots of accidental interactions, and those can easily cause
bugs.  You can't get a truly stable system by just mixing versions
together that haven't been tested together.  Just because A.m and B.n
are stable together, and B.n+1 is stable, doesn't mean that A.m and
B.n+1 will work together.

Does this matter for Squeak?  Probably.  How many people will figure out
which exact version of Morphic their module requires, for example?  How
do you know if your code works with the compatibility AlignmentMorph, or
if you need to switch to layouts immediately?  Ultimately, the easiest
thing to do is to try it, but that presupposes knowing what versions
(approximately) are available.


By the way, the "depends" relation makes it easy to put together
stable/unstable/whatever releases: have a "Squeak3.2" module that
depends on all the right modules for the 3.2 version, and have a
"Squeak-stable" version that depends on "3.2".  Then when you load
"Squeak-stable", you'll get the standard stable image.


-Lex