Julian Fitzell <julian at beta4.com> wrote on 16.07.2004 17:56:04:
>
>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.
>

The version number does not exist in the name of the method or the class, 
and we are referencing them in programs by their normal name only. That's 
what we are talking about here. It is the same as with Lex' proposal, we 
want to be able to reference a package in a dependency by its 
"version-stripped" name. Of course we won't drop the version information.

>
>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.
>

And that's why in other worlds a distribution is _released_, so that 
everything has the right version to work smoothly together. Lex' proposal 
is - as I understand it - not prohibiting that a package depends on a 
specific other one, it is expanding dependencies to be able to be version 
agnostic. And this kind of dependency is predominantly useful in the Full 
release.

>
>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...
>

Ok, I just reread my first post. I said "useful to work towards what Lex 
proposed quite some times now, modules that work together regardless of 
there version". I didn't imply that we should drop versioned dependencies 
(do we have them already?:) or the version info itself. It is just a good 
idea to be aware of a disease called "versionitis" (see my second post).

Saying that, I mean that mostly it is the right goal to keep the number of 
versions and especially branches in check, but not always and often it is 
not practical or achievable.

regards 
Martin