Martin Wirblat wrote:
> 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.

You make two valid points in here:
- minor changes to classes (or packages) are unlikely to affect their 
compatibility with other classes (or packages)
- we should always try to ensure that classes (and packages) remain 
compatible with their defined interface so that they are more likely to 
keep working with other classes (or packages)

But, first, your statement about version-numberd classes and methods 
being nonsense is a bit silly.  We already version all these things 
(looked at the Versions browser lately?) and we group particular 
versions of them together into a release (whether they be fileouts, mc 
packages, or whatever).  We don't bother giving them sequential version 
numbers but they do have timestamps which come to pretty much the same 
thing.  And you wouldn't expect to be able to take package A version 1.0 
and load 3 methods at random from package A version 2.5 and have it 
necessarily work.  So I think the exact case you say is nonsense pretty 
much already exists.

Second, nothing about either of your valid points implies that we 
shouldn't store the version numbers of packages that work together. 
While it may be true that version 1.01 of a package will work fine in 
place of 1.00, it's a pretty good bet that version 2.00 will not. 
Remember that we already have to deal with this issue with methods and 
classes, but that when a release is made, a set of methods and classes 
that all work together are made available all at once by a person or 
group.  When we're talking about packages, each one may be managed by a 
different person.  The author of Library A v.1.2 will likely release 
version 2.0 without all the hundreds of authors who use that library 
simultaneously releasing new versions of their applications.  At this 
point, nobody would be able to install those applications.

Third, there is an implicit suggestion in your reasoning that if you 
record the version numbers of compatible packages you are preventing 
flexibility of using newer compatible versions.  But this is just false. 
  The tools just have more information to determine that, if A-1.23 and 
B-2.34 work together, then it is likely safe to load B-2.36 but probably 
best to move up to A-1.27 instead of A-1.6.  The user can even still 
decide to try the newest versions, but if they have problems they know 
what working configurations to fall back on.  As Goran said in his 
reply, all you are doing is storing more information...

Julian