Hello,

A few months ago the NetBSD Core Team ratified the proposed changes
to the NetBSD version numbering scheme: From now on, we'll be using
the major version number to indicate a major release and the minor
version number to indicate a minor release. Following that, the
next major release is going to be 2.0 followed by 3.0. Patches to
2.0 will be numbered 2.1, 2.2, etc. and patches to 3.0 will be 3.1,
3.2, etc.

As some of you have noticed, we will need to do something about
NetBSD-current versions before we branch to NetBSD 3.0, otherwise
the version of -current (2.0H) will be behind the 3.0 release
branch. One way to do this is to move NetBSD-current to 3.0[A-Z]*
and continue what we have been doing. The other way is to use a
"99" versioning scheme, similar to other projects. This was proposed
by various developers, and after discussion, the NetBSD Core Team
agreed to switch NetBSD to using that.

Under this scheme, NetBSD-current will be indicated by having 99
as the minor release number, and using the patchlevel to indicate
different API levels within current. For example here is how things
will look for release 3:

OLD	NEW
3.0A	3.99.1
3.0B	3.99.2
3.0C	3.99.3
etc.

This change clarifies the relationship between "current" and
"release" versions of NetBSD. Before we had a situation where the
"release" version was "1.6.2" and "current" was "1.6C". Users were
getting confused about which one was they were supposed to be
installing, and which one was the most recent one. In reality one
cannot say which one was newer, but at least we hope that the "99"
in the version number will clearly indicate that this is a
"pre-release" or "current" version of NetBSD. From now on, as soon
as the release branch for release "M" is "cut", the version of
NetBSD-current will be changed to "M.99.0". This will indicate that
we are post release "M" and we are already referring to a pre-release
version of "M+1".  This version still has the same kernel ABI as
release "M" (thus the "0" in the patchlevel).

To summarize, a NetBSD version number will be indicated as:

    M.m.p

and internally:

    #define __NetBSD_Version__ MMmmrrpp00

where:

    M = major number
    m = minor number; 99 for current. 
    p = patch level used for security fixes only, or current revision number.
    r = 0; previously was the "release number" encoding "A-Z"

In addition, we are planning to add a:

    __NetBSD_Prereq__(M,m,p)       

macro, similar to the GCC ones. This could be defined as:

#define __NetBSD_Prereq__(M,m,p) (((M) * 100000000) + \
    (m) * 1000000) + (p) * 100) >= __NetBSD_Version__)

The following are examples of the new numbering scheme for release M:

M.0	bagged, tagged, and released
M.0.p	patch (p) releases for security fixes
M.m	minor (m) release
M.m.p	patch (p) releases to the minor (m) releases
M.99.p	current working branch where a change in 'p' denotes a kernel
	API change.

The following issues are not being handled in the current versioning
scheme:

1. For release engineering purposes, we are going to maintain the string
   suffix _BETA, _RC<N>, to indicate versions within the release process,
   and those changes are not going to be reflected in the version number
   (same as we are currently doing). (*)

2. There still will be no relationship between M.m and M.99.p, i.e.
   we cannot tell when a feature appeared in "current" and when it
   made it to M.m. Hopefully this is going to be less of an issue
   if we make more frequent releases. (**)

This change will take effect on 20041001, where we are going to move from:

    __NetBSD_Version__      200080000       /* NetBSD 2.0H */
to:
    __NetBSD_Version__      299000900	    /* NetBSD 2.99.9 */

The careful reader will note that we used "9" as the patchlevel which
would imply that we skipped a kernel ABI version number of safety
(since 9 would be "I" under the old scheme.


Christos Zoulas, on behalf of the
NetBSD Core Team <core@NetBSD.org>


--------
(*) One way we can encode the release engineering numbers is to set
    and "r" the last unused 2 digits to "99" to indicate an actual release,
    and use 0-><n> to indicate release candidates and ALPHA, BETA, etc.
    This is not proposed right now.

(**) Eventually, we'd like to find a way to relate M.99.p and M.m to
     simplify LKM versioning.