Hi Lex and all!

lex at cc.gatech.edu wrote:
> This is interesting but is not quite the way I work.  Multiple releases
> do sound useful; it's just that I wouldn't categorize them precisely as
> you describe.  I would like to have:
> 
> 	1. one stable release
> 	2. one unstable release
> 	3. both of the above for each version of Squeak that I support

Yes, but I think the current system should handle that. If you have
package "Quack" with these releases:

(1.2-3.7b) (r5)
1.1-3.7b (r4)
(1.1-3.6) (r3)
1.0-3.6 (r2)
1.0-3.5 (r1)		"Version 1.0 for 3.5, even added it to the manual version

Above I added the Squeak version to the manual version name, just to
make it more clear. Releases for 3.6 should of course be in that
category, and so on. And "Quack" itself should NOT be in any Squeak
version category - because right now that would mean that all releases
work in that version. And the releases should also be categorized with
"Stable" or "Bleeding edge" etc.

Anyway, the (rxx) is the automatic version number, which is allocated
strictly chronologically. May seem superfluous at the moment but they
are immutable and can handle branches when we add support for that.

So... Given the above the current stable for 3.5 is 1.0, likewise for
3.6 but for 3.6 there is an unstable release that is not yet published.
For 3.7 there is a published stable 1.1 release, but also an unpublished
1.2 release.

Btw... when I look at this now I can honestly say that the words
"published" and "released" should have been swapped. Kinda hard to do at
this time though, I mean conceptually.

It would probably have been better to talk about "versions" (=release
today) that you "publish" (=create a release today) and then "release"
when you commit to them (=publish today).

> Also, I don't understand why *all* old versions are supposed to be kept
> around.  So long as the newest stable release is there, what is the
> problem?  People who are that interested in my project should delve into
> the configuration management system, e.g. SqueakSource+Monticello, and
> get vastly more information than just the releases.
> 
> 
> Lex

Well, keeping older releases in the map has to do with the fact that
maintaining working configurations with dependencies may very well need
to handle more stable releases than just one.

But I should say that later - when we have dependencies in place - we
can start thinking about when and how older releases can be made
obsolete and deleted from the map, or at least archived in some way that
they don't suck up our bandwidth and storage :).

regards, Göran