I'm going to summarize responses to my versioning proposal.  The original
proposal is at the end.  My stab at requirements follows again, as nobody
seems to be arguing with them directly :-(  In particular, I wish people
would take a stand on #4, either "yes, I agree" or "no, that's not an
important requirement."

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

Bob Arning made an explicit response and also gave me an another idea (oh
no).  Bob's explicit response:

> I think an even clearer scheme would use the highest
> change set number in the third position. Thus, the 3.0
> image I downloaded a few days ago would be 3.0.3414.
> In fact, at this point the 3.0 becomes mostly sugar coating
> since the change set number basically tells it all.

I think this fails #4.

Like, when I was doing my testing against the various 2.9 images I just said
"the four 2.9alpha images" rather than "2.9.3076, 2.9.3125, 2.9.3144, and
2.9.3193", because those changeset numbers are all pretty opaque and hard to
remember.  If it was just "2.9.2, 2.9.3, 2.9.4, and 2.9.7" I would have just
remembered that and typed it from memory rather than (not) referring to the
directory listing.  This is a little unfair because I said I didn't wanna
number alphas, but you get the picture.

BTW, AmigaOS always had two version numbers.  There was an internal number
of the form "33.125" and a user-visible/marketing number like "1.2".  Come
to think of it, it's easier to market "3.0.1" than "3.0.3414"....

Elsewhere, Bob wrote:

> 3.1 with 3.0.a2 VM - '34538586 bytecodes/sec; 1047908 sends/sec'
(higherPerformance OFF)

I misread this as referring to a particular source version, but seen that
way it might be an answer to the "is 3.0 real yet" nomenclature problems:

Declare the initial image/changes that appeared on the ftp server to be
"3.0.a1".  Declare "3.0.a2" to be changeset 3446 applied (first bundle of
updates).  When SqCentral declares release time, that's the real "3.0.0".

Hopefully we won't have much need to refer to "3.0.a2" and pals in the
future, of course....

Steve Gilbert writes:

> So how is a sheep to keep track of the latest "stable" version.
> Well, from the www.squeak.org page the Downloading
> Squeak section leads you to a page that proclaims: "The
> current release of Squeak is 2.8 as of August, 2000".

Yes, and there were at least three reasonable versions of 2.8:

Initial release, 16 August 2000.
First round of updates, 18 August 2000.
Second round of updates, 4 October 2000.

So what do you get by downloading
ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/2.8/files/ ?  Uh, I think you get
the results of applying the first round of updates to the initial release.
I'm not sure.

Don't get me wrong, I think updates are good.  I *really* like it when the
maintainers of a system are issuing bug fixes to a stable release, because
it means that they care about the users of stable releases, not just
charging ahead on alpha development.  (Maybe I should send Alan Cox some
flowers for Valentine's Day or something.)  I think that hiding the fact
that updates have occurred is counterproductive.  I think 3.0 is going to
see a fair amount of maintenance as a stable release (which is good, yes)
which is why I'm trying to worry about this now.

Steve didn't address or argue with the requirements list, and the rest of
his message was a defense of the status quo.

Doug Way largely agreed with the strawman proposal.  Points from message:

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

OK, I can live with that.  Maybe 3.0.gamma1 and .gamma2?

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

[...]

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

I see one reason to have it in the image:

1) User can see it in the environment and not have to keep track of what
image/changes was downloaded initially and what updates were applied

I was going to add "2) Automated bug reporting tools" but anybody doing that
kind of thing is probably already set up to think about changeset numbers.

Jeff Szuhay agreed with Doug, and added:

> The problem with using the changeset numbers is that they don't
> alway apply to specific version.
[...]
> For Squeak and related parts (Whisker, STP, Siren, etc.) a version could
> then refer to a package of parts each with their own versions.

I think that leads down the "Squeak modularization" rathole, which isn't
gonna help with the versioning issue right now---is that why Jeff added the
"8-)"? :-)

Henrik Gedenyrd suggested:

> That was why I suggested that change sets be numbered from 30000 for
> 3.0 and 31000 for 3.1 and so on.

Bob Jarvis replied:

> SC is then limited in the number of change sets which can
> be issued under one version.  Under the 30000/31000 scheme
> there are a maximum of 999 changes which can be applied to a
> version.  Adding extra zeros will delay the problem but won't
> eliminate it.

David Lewis pointed at http://netjam.org/smalltalk/versions.html , which in
the context of stable Squeak releases boils down to my strawman, as I read
it.

Jay

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