[I'm going to hate myself for chiming in here...]

We (seem to) have decided that the next release series (including
patch rev's) will be 2.x - ie, we drop the third digit.  I am glad
to hear this, I've been advocating this position for some time.

The people proposing version schemes with *four* dot-separated
parts illustrate exactly why I dislike the three-part ones; too
complex.  We just don't make enough releases to need the numbers.

In this scheme, as previously discussed, releases go
 2.0, 2.1, 2.2 for releases off the next branch.
 3.0, 3.1, 3.2 for releases off the branch after, that include new
               stuff from -current beyond the normal pullups.

What hasn't been discussed (up to now) is how to name -current
under such a scheme.  I like the present scheme, but the choice
(assumed) above requires a change to this too, it breaks the pattern:

 * I think we all assumed it would be 2.0A after the branch is created
   - but hadn't quite noticed that after the 2.1 patch release comes
   out, -current would still be 2.0R or whatever.. I think this creates
   a different kind of problem, it seems to imply that 2.1 contains
   more stuff from development in -current than it does. This is
   *worse* than the present confusion over whether 1.6.1 has stuff
   from 1.6R in it.

 * If we were to follow the pattern we have now, but shift the digit
   as well, -current becomes 2A. I'm not sure I like that, nor that
   many others would.

However, I don't really like any of the proposed schemes in this
thread.  Before I propose another, I'd like to list some features
I think we want (and that each of the proposed schemes lacks
somehow).

 - as simple and obvious as possible (no minor-minor-minor version
   numbers unless we're really changing them every week)

 - something that shows the clear differences in kind between bumps
   of -current and bumps of the release branch (not just odd/even
   numbers). These changes reflect different kinds of work.

 - something that shows the clear difference between the releases
   (off whatever branch) and -current.

 - something that helps users understand the lineage and branching
   structure, so they know what they're getting.  This is especially
   important if we ever get so good at doing releases that we have
   intermingled (in time) releases off several branches.

 - something that avoids the "subtractive" version number problem, where
   1.7X < 1.7, or to a lesser extent, 1.7_BETA < 1.7 (I think users
   are comfortable/clear enough on the latter).
 
 - something that lets developmental versions (current and along
   the branches) be identified.

So, I propose:

 - Each release series takes a major number (2.x 3.x)

 - Minor number (2.0, 2.1, 2.2) represents the amount of release
   engineering effort.

 - Therefore, the first tested release is n.1 (2.1), *not* n.0.

 - n.0 represents -current up to the branch that leads to n.1, n.2, ..

 - -current continues to use a letter to indicate both incremental
   API/ABI changes, as well as its different nature.  This would
   be as now - 2.0A, 2.0B - or just possibly 2.0.A, 2.0.B, ...

 - when we branch, current becomes 3.0A (3.0.A)

 - releng gets to make the call on what to name incremental points
   leading up to actual formal releases: the 2.1_RC1 style names.
   I'm perfectly happy with _RC or _PRE. 

 - Likewise _STABLE between minor releases.  While it might be
   tempting to use 2.1.1 or even 2.1.A for -stable points, doing so
   risks confusion with -current and with our present scheme.
   If a minor-minor number is used here, I'd like to see it serially
   increment with each pullup, so it's *clearly* different to
   present usage.

This scheme *doesn't* match what developers and cvs users see as
the branch point like our present one does - we have version numbers
of 2.0X before there's a netbsd-2-0 branch. That's a shame, but
since we seem to be so worried about confusing the newbies rather
than the experienced developers, we need to favour them and expect
developers to understand the difference. The branch tag itself
would probably be better called "netbsd-2", in this scheme.

This does much better match what end users see as the final polished
result of our development efforts in -current and releng efforts
along the branch.

Taking it further (and perhaps too far?)

 - 2.A, 2.B for current leading up the the 2.x branch
 
 - 2.0 for the branch point (when current becomes 3.A)

 - 2.0.nnn for the nnn'th pullup on the 2.x branch prior to 2.1

 - 2.1 for the first release

 - 2.1.nnn for each pullup thereafter

Perhaps the key point about this scheme is it only took 5 lines to explain.

--
Dan.