Subject: Re: NetBSD version naming - suggestion
To: None <firstname.lastname@example.org>
From: Alan Barrett <email@example.com>
Date: 04/25/2003 19:17:47
On Thu, 24 Apr 2003, firstname.lastname@example.org 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
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
If we combine that with the "ninety-something means soon before next
release" convention, then we could have this:
188.8.131.52 -current some time after 2.4.x branch is created
| but before 2.5.x branch is created
184.108.40.206 ----. branch point of 2.5.x release branch
220.127.116.11 18.104.22.168 -current and 2.5 branch after branch is created
| 2.5.1 first formal release from 2.5.x branch
| 22.214.171.124 first commit on 2.5 branch after 2.5.1 release
| 126.96.36.199 start of releng cycle before 2.5.2 release
| 2.5.2 formal release of 2.5.2
188.8.131.52 somebody decides that the next formal release
| will be 3.0.1, not 2.6.1.
184.108.40.206 -----. 3.0.x branch is created
220.127.116.11 18.104.22.168 -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 "22.214.171.124-CURRENT", "126.96.36.199-STABLE",
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 188.8.131.52 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)