On Thu, 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	...

That looks OK to me, except you glossed over what happens after the 2.x
branch is created but before the 2.0 release, and you assume that each
major release uses a new value in the first dot-separated part of the
version number.

My suggestion is that <major>.<minor> and <major>.<minor>.0 releases
never happen.  Instead, the first actual release with a given
<major>.<minor> value is <major>.<minor>.1.  The main line (-current)
has 0 in the third position, and an incrementing number in the fourth
position.

If we combine that with the "ninety-something means soon before next
release" convention, then we could have this:

  2.5.0.41              -current some time after 2.4.x branch is created
     |                  but before 2.5.x branch is created
     |
  2.5.0.42 ----.        branch point of 2.5.x release branch
     |         |
  2.6.0.1   2.5.0.90    -current and 2.5 branch after branch is created
     |      2.5.0.91    
     |      2.5.1       first formal release from 2.5.x branch
  2.6.0.2      |        
     |      2.5.1.1     first commit on 2.5 branch after 2.5.1 release
     |      2.5.1.2
     |      2.5.1.90    start of releng cycle before 2.5.2 release 
     |      2.5.1.91
     |      2.5.2       formal release of 2.5.2
  2.6.0.3
  3.0.0.1               somebody decides that the next formal release
     |                  will be 3.0.1, not 2.6.1.
     |
  3.0.0.2 -----.        3.0.x branch is created
     |         |
  3.1.0.1   3.0.0.90    -current and 3.0 branch after branch is created
            3.0.1       first formal release from 3.0.x branch

Add suffixes if you like, to get "2.6.0.1-CURRENT", "2.5.0.90-STABLE",
"2.5.1-RELEASE".

This way has the following useful properties:

  * There are no confusing letters.  The confusion about whether "1.6A"
    is equal to "1.6-ALPHA" just doesn't arise.  Any suffixes (like
    "-STABLE", "-CURRENT", etc.) are optional extras, not important
    parts of the version number.

  * Because 2.6 is obviouly larger than 2.5, it's easy to explain to
    people that "upgrading" from 2.6.0.2 to 2.5.2 is not actually an
    upgrade.  Compare this with the difficulty of explaining that
    "upgrading" from 1.6F to 1.6.1 is not actually an upgrade.

It has the disadvantage that "x.y.0 releases never happen" is an
unusual rule today.

Not that, if you are willing to burn a new first-level version number
every time you create a new release branch off the trunk, then the ugly
4-part version numbers can trivially be reduced to less ugly 3-part
version numbers.  Imagine "7", "8", "9" instead of "2.4", "2.5", "2.6"
in my above examples.

--apb (Alan Barrett)