Jay Carlson wrote:
> 
> I'm going to try to write down a set of requirements/desires for how to
> version software, mostly from the perspective of what I called "sheep":
> people not involved in the day-to-day development of the core system, who
> intend to support and build software outside it.  There's a bit of overlap
> with the requirements with those of people referred to as "packagers" (or
> "distribution builders" in the Linux world), but sheep are dependent on
> packagers for the most part.

"Sheep" sounds a little harsh... I think I prefer the term "non-test-pilots". :)  But I think we agree on the concept.

> 1) Every reasonable source state that sheep encounter should have a distinct
> name.  If there is reasonable uncertainty about derived binaries or images,
> they should have a distinct name too.
> ...
> 
> 2) Sheep expect community-wide released versions to be named with numbers.
> ...
> 
> 3) Numbered versions are monotonically increasing, and it's easy to guess
> the relationship between versions from the names.
> ...
> 
> 4) Sheep want names to be short, snappy, and easy to remember and type.
> ...
> 
> 5) Sheep want broad consensus on what a particular name refers to.
> ...
> 
> 6) Sheep want the core developers to be happy and productive and
> unconstrained in their future development.
> ...

I agree with all six of your points here, including #4.

> So here's my proposal.
> 
> Nothing changes for 3.1alpha.  Update numbers already work.  Sheep don't
> care.
> 
> The image, sources, and changes files that were put up for FTP become
> "3.0.0".  They're already loose in the world, they deserve a name.
> 
> Each bundle of updates released by SqCentral gets a minor rev number.  That
> means that we're at, uh, "3.0.1" now, right?  Anyway, minor revs then refer
> to particular offsets in the update stream.

Actually, no, I don't think we're at 3.0.1 (or even 3.0.0) yet.  I'm pretty sure we're still at 3.0gamma, or whatever it's called.  My guess is that whatever is shipped out on the CD-ROM will be considered the first official 3.0 release.  In any case, it seems pretty clear that sheep/non-test-pilots should not be using 3.0 yet at this point.

Normally (when there isn't a CD-ROM involved), a new release isn't really official until the www.squeak.org site is updated to include the new version.  (This hasn't happened yet for 3.0.)

At least I think the above is all true.  I guess a more formal 3.0.x scheme would clear things up a little as to whether 3.0 is "official" yet.

> If I had write access to the update stream, this would be really easy to
> implement: issue a changeset that just bumped a minor rev counter after
> every update bundle.  As a bonus, the rev-to-update-number mapping becomes
> very easy because it's marked in-band.
> 
> Nobody has to build packaged image/changes for every minor rev, but when
> they are built they're named properly.  So maybe uiuc archive has .ZIP files
> of "3.0.0", "3.0.1" and then "3.0.7".  I'm not asking for more frequent
> packaging---well, more to the point, I'm not volunteering to do it, either.
> :-)
> 
> I don't know what to do about VMs.  Because they're somewhat decoupled from
> most updates, naming them "3.0.2R5" for the fifth build of a VM built from
> 3.0.2 seems overkill.  Maybe the best name is something like "Win32 3.0R4";
> that's kinda what we're doing now.  VM version names have to have their own
> namespace for revs because of that decoupling.
> 
> Somebody puts up a page on the Swiki describing all this.  Perhaps publish
> md5 checksums of particular changes files too, if that's useful.  If we need
> a place to archive packaged versions, Sourceforge does OK at it.
> 
> I'm running late.  Can people please add/remove requirements or shoot at
> this proposal?  I'm trying to balance cost/benefits for core/sheep, so bonus
> points if you take that into account.

It sounds generally good to me.  I agree that 3.0.1, 3.0.2, etc., are generally easier for regular non-test-pilot users to refer to and remember, rather than 3.0.3446 or 3.0.3462.  (And yes, these 3.0.x numbers would only refer to post-official-release bugfix versions, not any alpha or beta versions.  We can still use 3.1alpha-3522 etc. for these.)

Actually, I remember there was a problem with 2.4, I think, in which there were serious bugs in the official release, so there was also 2.4a and 2.4b post-release versions.  So, this type of solution has been used before.  (2.4.1 would probably be better than 2.4a, to avoid confusion with a = alpha.)

The trick is to handle this in such a way that it's not too much of a hassle for Squeak Central, since I'm not sure if they're too enamored with the idea.  Perhaps this could just be handled by the ftp site curator, which would be Bruce O'Neel.  As a new batch of post-release updates came out, he could bump up the version number on the image which he copies to the uiuc ftp site.  E.g. Squeak3.0.1.image, Squeak3.0.1-win.zip, etc.  Of course, this is up to Bruce.

(Although it would be sort of nice to be able to query the minor version number (e.g. 3.0.2) from within the image, but I don't know if it's critical.)

- Doug Way
  dway at riskmetrics.com