[ On Thursday, August 1, 2002 at 22:58:42 (+0200), Alistair Crooks wrote: ]
> Subject: Re: Comparing version numbers
>
> 'rc' encodes as release candidate, which is -1

No, not just "-1".  How do you compare "1.rc2" against "1.rc3"?

I suggest that "rc" should mean "insert '.0.'":

	1.rc1	=>	1.0.1
	1.rc2	=>	1.0.2
	1.rc2.1	=>	1.0.2.1

and so on....

Unfortunately this can still be confused by bizzare numbering schemes,
but I think it's better than trying to figure out how to use negative
numbers when things get more complex....

(eg. 1.rc1, then 1.rc2, then 1.0, but correctly it should be 1.1)


-------------------------------------------------------------------------

Now if only all "vendors" would use this scheme that I use  :-)

Release Numbers:

We essentially follow the essence of the Berkeley CSRG version numbering
scheme for identifying releases.  That is to say we increment the third
number (3.7, 3.7.1, 3.7.2, etc.) whenever we generate a release of bug
fixes (what might traditionally be also known as a "patch" release), and
we increment the second number, or the minor release number, (3.7, 3.8)
whenever we add any new features or make other important user-visible
changes, and lastly we increment the first number, or the major release
number, (3.*, 4.1) whenever we make major or architectural changes.

We also throw in a smattering of GNU-isms too -- the alpha-test and
beta-test releases of upcoming proper releases should have a ".80" or
".90" (respectively) appended to the current release number (3.7.5.80
would be the first alpha for 3.7.6, continuing with 3.7.5.81, 3.7.5.82,
etc., 3.7.5.90 would be the first beta, continuing with 3.7.5.91,
3.7.5.92, etc. until finally 3.7.6 is released; for another example the
first alpha for 4.1.1 would be 4.1.0.80, continuing with 4.1.0.81,
4.1.0.82, etc., 4.1.0.90 would be the first beta, continuing with
4.1.0.91, 4.1.0.92, etc., until finally 4.1.1 is released).

One special case rule not yet described covers the releases preceding
the initial release, which would might start with semi-private releases
numbered "0.x", eg. 0.1.80, 0.1.90, 0.1.91, 0.2, 0.2.80, 0.2.90, 0.3,
etc., then full public releases numbered "1.0.x", eg. 1.0.80, 1.0.90,
etc. until 1.1, the first fully official release is made.

Note that there are no '.0' releases!  I.e. ".0" is only used as a
separator between initial major releases and the first minor release,
and between initial minor releases and the first patch release.

Ideally patch releases will be developed on a release branch to permit
parallel development of new features on the trunk for the next minor (or
major) release (with folding of fixes and features as necessary back to
the trunk).  In theory minor releases could also be developed on release
branches, but only in situations where extreme levels of maintenance for
existing releases must be undertaken.

You'll note this effectively caps the maximum patch level, and the
maximum minor release number, to a ceiling of ".79", and limits the
number of alpha releases to just 10.  Unfortunately it does not limit
the number of beta releases since things like .100 are allowed!  ;-)

If you see "-Preview.N" appended to the release number then you're
seeing an intermediate development copy -- i.e. an as-yet un-released
copy which will likely have the release number given with the suffix
stripped when it is finally officially released.


-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>