Sorry if I picked the wrong list for this, it was the closest
I could find.

Also, please don't take this as an attempt to start a naming war,
it is just intended as a suggestion that may simplify things for
some (many) people.

I'm sure everyone has noticed the general confusion that the 1.6X
type naming has for many people, with people believing they're
upgrading from 1.6R to 1.6.1 (which I'm sure we're going to see
again when 1.6.1 is announced).

While the current naming scheme for -current is functional, and
makes some sense once you're used to it, I believe it is doing NetBSD
a dis-service in the long run.

As NetBSD 2.0 is approaching (no idea when, and it doesn't matter for
this) I'd like to suggest that NetBSD change its version numbering
scheme starting at 2.0 (or actually, starting in the lead-up to 2.0).

The suggestion is that all NetBSD versions use N.M.R type numbering,
including -current.

In that N is the '1' we have now, and the '2' we're going to get (this
scheme would start with N==2) - maybe sometime in the distant future
it will turn into 3, maybe never - that decision would be made exactly
as it is getting made with the change from 1 to 2 now - no difference at all.

For M though, I'm going to suggest that only odd values of M be used for
releases (stable versions), leaving even values of M (including 0) for
what is now -current.

Then for release versions, ((M & 1) == 1) R would be processed exactly as
now, incremented by one for each new upgrade release of a previous
release (exatly as 1.6.1 compared to 1.6 (or 1.6.0 except it is hasn't been
called that).   R would always be included, so 2.1.0 would be the first
real release after the 1.6 series.

For -current ((M & 1) == 0) R would be processed just like the current letter
after current releases, incremented whenever an internal kernel interface
alters.  I'd actually like to see that happen periodically, if there has been
no other reason for an increment (say 3-4 weeks after a version bump a new
one happens) but that's a completely different discussion (and would apply
to the letter number scheme as well - except that there are lots more
available integers than letters , 1.6ZZZZG would start being absurd, but
1.6.111 much less so, so this disincentive against frequent bumps would go
away, requiring LKM's to be (needlessly) recompiled would remain).

Operationally, what this means is that sometime in the lead up to 2.0
NetBSD's version would be changed to 2.0.0, then 2.0.1 2.0.2 (these
replacing the 1.6X type names - I'm suggesting that this switch
happens with the next version bump after 1.6Z).

Then, once 2.1.0 is ready to be branched, the head becomes 2.2.0, and
further development of -current continues there.

The 2.0.R series continues, now being alpha/beta/RC/... pre-releases for
2.1 (so there is no more NetBSD-1.6_RC3 type stuff).

Once that's completed (all the tests are finished, no more bugs to be fixed,
etc), 2.1.0 replaces 2.0.R and that's the next NetBSD release.

From that point, the normal pullups happen from the 2.2.R series, back
into 2.1.0 tree, and when there's enough, or some other good reason,
2.1.1 is released (no intent to change how those decisions are made).

The 2.2.R versions keep on going, and once there's enough new stuff for
a major new release, a branch is made, 2.2.R continues on the branch, and the
head is changed to be 2.4.0.

The 2.2.R versions continue being effectively alpha, beta, RC, ... versions
for what will become 2.3.0 once everything is fully tested, fixed etc.

And current is continuing as 2.4.R - and so on, forever (until it is time
for NetBSD 3).

Once again, the only suggestion here is to change the version naming, all
the real changes/decisions/policy gets done exactly as it now does.

The result of this change (or perhaps something else like it) is that
if a version is "more enhanced" than another, its version number will
always be obviously larger, and no-one is going to consider switching from
2.4.15 to 2.3.1 as being an upgrade.

I'd also suggest keeping the "RELEASE" "STABLE" "RCn" (though I might just
call that "CANDIDATE" to be more obvious) and "CURRENT" labels.

"CURRENT" would be applied to N.M.R where (M & 1) == 0, and where there is
no larger N.M for which that is true.

"CANDIDATE" would be applied to N.M.R where (M & 1) == 0, but where there is
another version (N.M) that is bigger (ie: something else is CURRENT).
These exist only during the period between when current is branched and
the new version is released.

"RELEASE" would be applied to N.M.R where (M & 1) == 1, but only very
briefly.   It would be set to that immediately a new N.M.R version identifier
is created, and while it remains, no alterations at all would be permitted
on that branch (no matter what, or how serious the security glitch just
found happens to be).   At that point, all that can be done with the
sources is to compile & ship them.   As soon as that's out of the way
(or even abandoned), the label changes to "STABLE" and updates can begin again.

This label would be included in uname output, and in the kernel version banner
at boot time (and anywhere else appropriate).

Anyway, that's it - just a strawman for consideration by the community.

kre