Release Numbering Scheme

Current

ntp-4.2.2 marks a change in the way releases are numbered.

The syntax of a name is: Version[Point][Special][ReleaseCandidate]

where Version is A.B.C, and:

• A is the protocol version (currently 4).
• B is the major version number.
• C is the minor version number. Even numbers are -stable releases, and odd numbers are -dev releases.

Point is the letter p followed by an increasing number.

Special is currently only used for interim projects, and will generally be neither seen nor used by public releases.

ReleaseCandidate is the string -RC.

Note that ReleaseCandidate numbering is slightly different for -stable and -dev.

For -dev the -RC suffix is just a suffix - the Point number increases with each new release. If, for some reason, we decide that the release must be delayed we simply stop using -RC with the next (incremented) Point number. When the release is finally made, the minor number for -dev increments to the next odd number and the point number is reset.

For -stable the situation is a bit different. Any change to -stable should be a -RC, and since there may be several iterations, we will start with -RC1 and increment from there.

Also see the download area layout.

Pre-4.2.2

NTP uses A.B.C. - style release numbers.

The third (C) part of the version number can be:

   0-69 for releases on the A.B.C series.
   70-79 for alpha releases of the A.B+1.0 series.
   80+ for beta releases of the A.B+1.0 series.

At the moment:

   A is 4, for NTP version 4,
   B is the minor release number.
   C is the patch/bugfix number, and may have extra cruft in it.

Any extra cruft in the C portion of the number indicates an "interim" release.

Interim releases almost always have a C portion consisting of a number followed by an increasing letter, optionally followed by -rcX, where X is an increasing number. The -rcX indicates a "release candidate".

Now that we have more active changes to both the -stable and -dev branches, we should find a way to better identify code that is derived from one of these branches.

Here are some recent version numbers as an example:

   4.1.0 — A production release from the ntp-stable repository.
   4.1.0b-rc1 — A release candidate for 4.1.1 from the ntp-stable repository.
   4.1.71 — An alpha release of 4.20 from the ntp-dev repository.

Note that after the ntp-dev repository produces a production release, the release will be copied into the ntp-stable repository and the cycle will repeat.

The goal of this scheme is to produce version numbers that collate properly with the output of the ls command.

Further thoughts

We could always bump the 2nd number for each release and use the 3rd number for patches and stuff.

Now that we plan to have more frequent releases this may not be all that useful.

We could also go to -plN suffixes for patch releases. This might require some changes to the version.c code, or the mkver script. I think I like this better.

As far as the bk repos go, I am now using a as a suffix for ntp-stable and b as the initial suffix for ntp-dev releases. If I discover that Dave Mills has released a tarball on his own the ntp-dev suffix should be bumped. Note that Dave only works in ntp-dev and never in ntp-stable.