Lantz Rowland wrote:
> 
> ...
> > > The primary concern, seems to be that a person with no prior knowledge of
> > > Squeak Release numbers, will discover the Ftp site and incorrectly assume
> > > that since release 3.1 is greater than release 3.0, that is the release
> > > they should get.
> >
> >The current scheme does an excellent job of addressing this, IMHO, since
> >you have to dig a bit to find a 3.1alpha directory, but it's easy to find
> >the current 3.0 production release.
> >
> >I guess your concern is that it's currently a bit too difficult for
> >someone to find the development (alpha) release?
> 
> Not at all. I disagree that 3.1a is a kind of 3.0 release. It does not
> belong in that directory at all, even to hide it. There has never been an
> alpha release of 3.0 and there never will be. I mostly disagreed with that
> folder name and either '3.1' or 'alpha' being inside the 3.0/ folder.

Okay, now I see what you were trying to say.  That is a good point... the 3.1alpha release has no special connection to 3.0, so perhaps it would make sense to move it out of the 3.0 directory.

> I did
> make an assumption as to the only reason I could think of why the folder
> '/3.1/' or '3/1_alpha/' had not been created and why it had been hidden, to
> which I proposed creating the 3.2 folder now, and apparently completely
> confused things.

Aaahhh, so you were thinking that Squeak *currently* uses an even/odd version numbering scheme and you were describing that, rather than proposing that Squeak switch to an even/odd numbering scheme.

I guess I can see how you might have thought that, given the releases since 2.8, but no, Squeak does *not* currently use an even/odd version numbering scheme.  It was just coincidence that 2.9alpha ended up being a development-only version, though... a decision was made to change the final release name from 2.9 to 3.0 at the last minute for various reasons, to go with the upcoming Squeak book CD-ROM.  But that was the exception; otherwise the process has always been 2.4alpha (development) -> 2.4 (production) -> 2.5alpha (development) -> 2.5 (production) -> 2.6alpha (development) etc.

> >I think it should be somewhat hidden, although I suppose it could be made
> >slightly less hidden by renaming the unstable-testPilot directory to
> >unstable-3.1alpha or something like that.  (Although I wouldn't mind
> >leaving it the way it is, either.)
> 
> While I prefer just using the simple release number '/3.1/ as opposed to
> '/3.1a/' , '/3.1_alpha/' , or '/3.x_alpha/' for the root level folder name
> as I explained before, I would have no trouble using of those. I personally
> do not perceive any need to hide the source of an Open Source project
> though Bruce obviously liked the idea too. Perhaps a root folder named
> '/Magic/' , '/TestPilot/' or just '/HiddenStuff/' if not '/3.x_alpha/' .

I would probably prefer a name like '/3.1alpha-unstable/' if it's moved to the root level.  That way it's still easy to find, since it would appear in order after the 2.8, 2.9, 3.0 directories.  But the word "unstable" would still warn people that this is a (relatively) unstable, alpha, non-production, development release.

This last point is important... the whole reason that the alpha directory is currently hidden is that, previously, newcomers would see the e.g. 3.1 directory as the most recent one, and they would download that version because it must be the current/latest release, not realizing that it is more unstable and often incompatible with external apps/goodies written for 3.0.  Then they would get frustrated and complain to the list that "Squeak is unstable, filing in these changesets doesn't work, Squeak must be inherently unreliable", etc.  Basically, newcomers should not be using 3.1alpha as a general rule.

> My primary concern is that the Symbols #unstable , #testPilot, #3.1 and
> #alpha have nothing at all to do with the Squeak3.0 Release and we need to
> move them out of the /3.0/ folder. The reason I consider this both
> important and time critical is due to how fast hypertext references can
> propagate.

Good points.

- Doug Way
  dway at riskmetrics.com