Hi Göran,
>
>> On 15 juil. 04, at 17:19, lex at cc.gatech.edu wrote:
>>> 3. Number two is, as you suggest, to have dependencies between
>>> packages.
>>> They do not need to be complex as we get going, but please do make
>>> them
>>> based on packages not particular versions.  At the distribution level,
>>> the dependencies should be like "Scamper needs URL", not "Scamper 1.5
>>> needs URL 1.3".  This is because, within a distribution, users almost
>>> always want to have the newest versions of the packages.
>
...
>
>I agree with you Stephane. IMHO the only thing that I can promise is
>that a certain set of *releases* (=versions) work together. I can't
>promise that the newest release of Y works with X 1.2, because that is
>*in the future*.
>

Putting modules together is similar to "normal" programming, just on a 
larger scale with a coarser granularity. We are expecting a Smalltalk 
Class to stay the same when we change something (minor) in it in the 
sense that it should serve its clients the same way it did before. 
Programming is speaking a language for our brains. Adding version numbers 
would be an explosion of the vocabulary. To give classes or methods 
version numbers would be nonsense. You want to assure that the core 
functionality is as universal as possible and that it stays the same as 
long as possible. Every programming style which does not adhere to this 
principle is less efficient if not impossible. And because "moduling" is 
programming, it is useful to work towards what Lex proposed quite some 
times now, modules that work together regardless of there version.

The same argument applies to UUIDs. Working with modules is programming, 
and using UUIDs in the language necessary to do so, is a step backwards. 
Please don't say here, that everyone can use names. Real world shows that 
the UUIDs are creeping in everywhere. If SM modules will live up to what 
you hope for, we are going to have a Smalltalk with random vocabulary, if 
we can't get rid of the UUIDs.

To answer your original question, I think your work on SM is really great 
and has made a big psychological impact on everyone interested in Squeak. 
There is no need to fear that it may become obsolete just because a 
somewhat different alternative may arise somewhere in the future.

regards 
Martin