[ On Friday, April 25, 2003 at 03:52:56 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: NetBSD version naming - suggestion
>
> On 24 Apr 2003 cgd@broadcom.com wrote:
> > 
> > I've become a fan of the gnu-ish "ninety-something" version numbering,
> > for development-trunk versions, e.g.:
> >
> > 	2.0	major
> > 		2.0.90	branch development before release
> > 		2.1	patch release
> > 		2.1.90	branch development before release
> > 		2.2	patch release
> >
> > 	2.90.0	development before next major.
> > 	2.90.1	development before next major, after abi change.
> > 	2.90.2	...
> >
> > and if for some reason something *really* major happens on the trunk
> > or branches, one could use 91, 92, etc.  8-)
> 
> I like that, too. It's very intuitive

I have used a somewhat more complex but more complete variant if this
scheme for some time.  Its primary advantage is that it eliminates those
pesky untrusted ".0" releases.  It is also extended to cover the
official beta and release candidate naming for both minor and patch
releases.  This means it gets rid of the "names" for beta and release
candidate releases and just gives them all special sequences of numbers.

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

I also throw in a smattering of GNU-isms too -- the beta-test and
release candidates 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 beta for 3.7.6, continuing with 3.7.5.81, 3.7.5.82,
etc., 3.7.5.90 would be the first release candidate, continuing with
3.7.5.91, 3.7.5.92, etc. for additional release candidates as needed
until finally 3.7.6 is released.

Another example covers the very beginning of a patch series 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 alpha, continuing with release
candidates 4.1.0.91, 4.1.0.92, etc., until finally 4.1.1 is released).

I usually try to use branches for patch releases, just as in NetBSD, so
that more ground-shaking changes can occur on the trunk while still
making it possible to create ongoing patch releases.

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

The ABI changes along the trunk can be dealt with by modifying the beta
scheme so that ".80" starts the new development (just as Chris starts
new development with ".90" above), and then appending an incrementing
suffix number to the ".80" starter number, as per Chris' suggestion.
The first true beta release would then be ".81".  ABI changes could be
handled along any line of development, but for practical purposes they
would still be restricted to the trunk.

The ".90" label could be modified to just indicate the start of release
candidate development, with the first actual official release candidate
being ".91".

To repeat in in excruciating detail an expanded version of Chris'
example from above with my changes added, and going right back to the
beginning, so as to try to avoid any possible mis-interpretation:

	0.0		project concept published

		0.0.80		begin initial development
		0.0.80.1	after first ABI change
		0.0.80.2	after second ABI change
		...
		0.0.90		pre-release RC #1
		0.0.91		pre-release RC #2
		...
		0.1		first pre-release

		0.1.80		begin second pre-release
		0.1.80.1	after ABI change
		...
		0.1.90		2nd pre-release RC #1
		0.1.91		2nd pre-release RC #2
	
		0.2		second pre-release

	1.0.80		begin first official release
	1.0.80.1	after ABI change
	1.0.80.2	after ABI change
	...
	1.0.81		first beta
	...
	1.0.90		first official release candidate
	1.0.91		second official release candidate
	1.0.92		third official release candidate

	1.1	first official release

			1.1.0.80	begin branch development
			1.1.0.81	1st beta
			...
			1.1.0.90	1st release candidate
			1.1.0.91	2nd release candidate
			....
			1.1.1		first patch release

			1.1.1.80
			1.1.1.81
			...
			1.1.1.90
			1.1.1.91
			...
			1.1.2		second patch release

		(in parallel with the 1.1.0.80 patch branch)
		1.2.0.80	begin minor release
		1.2.0.80.1	after ABI change
		1.2.0.80.2	after ABI change
		1.2.0.80.3	after ABI change
		....
		1.2.0.81
		...
		1.2.0.90	second official release beta #1
		1.2.0.91	second official release beta #2
		...
		1.2	second official (minor) release

			1.2.0.80	begin branch development
			1.2.0.81	1st beta
			...
			1.2.0.90	1st release candidate
			1.2.0.91	2nd release candidate
			...
			1.2.1		first patch release

			1.2.1.80
			1.2.1.81
			...
			1.2.1.90
			1.2.1.91
			...
			1.2.2		second patch release

		(in parallel with the 1.2.0.80 patch branch)
		1.3.0.80	begin next minor
		1.3.0.80.1

	. . . and so on to where we are now with 1.6 . . .

	2.0.80		begin new major release (bump trunk)
	2.0.80.1	after ABI change
	2.0.80.2	after ABI change
	2.0.80.3	after ABI change
	...
	2.0.81		first beta
	...
	2.0.90		first RC
	2.0.91		second RC
	...
	2.1		second major release

			2.1.0.80	begin branch development
			2.1.0.81	1st beta
			...
			2.1.0.90	1st release candidate
			2.1.0.91	2nd release candidate
			....
			2.1.1		first patch release

			2.1.1.80
			2.1.1.81
			...
			2.1.1.90
			2.1.1.91
			...
			2.1.2		second patch release

		(in parallel with the 2.1.0.80 patch branch)
		2.2.0.80	begin next minor release
		2.2.0.80.1	after ABI change
		2.2.0.80.2	after ABI change
		2.2.0.80.3	after ABI change
		....
		2.2.0.81	first official beta
		...
		2.2.0.90	first official release candidate
		2.2.0.91	second official release candidate
		...
		2.2		next official (minor) release

			2.2.0.80	begin branch development
			2.2.0.81	1st beta
			...
			2.2.0.90	1st release candidate
			2.2.0.91	2nd release candidate
			...
			2.2.1		first patch release

			2.2.1.80
			2.2.1.81
			...
			2.2.1.90
			2.2.1.91
			...
			2.2.2		second patch release

		(in parallel with the 2.2.0.80 patch branch)
		2.3.0.80	begin next minor release
		2.3.0.80.1

	3.0.80

This might look like it adds another branch, but it doesn't have to.  It
just depends on whether you want to bump the trunk to start the next
major release, or whether you do want to go out on a branch for minor
releases.  If you want to bump the trunk then at any point along the
trunk when it's decided that the next release will be called a "major"
release then 1.N.0.80.x can be promoted to become 2.0.80.x, just as in
my example above.  In a volunteer project it's already asking a lot just
to use branches for patch releases, let alone minor releases.

You'll also note this scheme effectively caps the maximum patch level,
and the maximum minor release number, to a ceiling of ".79", and limits
the number of beta releases to just 10.  Unfortunately it does not limit
the number of release candidates since things like .123 could be
permitted!  Ideally though to eliminate confusion the maximum patch and
minor numbers should be limited to a ceiling of ".49".

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