I'm way behind on my NetBSD list reading (like ~ 20K messages) so
I'm not sure if this has been covered before or not (but I did attempt
to scan the list (grep) and see if there was any discussion, and found
nothing) - if so, please just ignore this mail.

I am a little concerned about the planned NetBSD version numbering
scheme changes.   That is, for the next release to be 2.0 (that's
fine) and then the next patch release to be 2.1, whereas -current
is on the path towards 3.0

Now I'm not concerned about this because I care about the numbering
scheme, that's pretty much irrelevant.

My concern is upon the way it all affects __NetBSD_Version__ (from
sys/param.h).

Up to now (and including right now) it has been true that
__NetBSD_Version__ for any version of current after a release
has been greated than __NetBSD_Version__ for any point level
patch release of that version.

That is, assuming by NV(x) I mean the value of __NetBSD_Version__
for the release we know as x then

	NV(1.6A) > NV(1.6.n) for any n.

But
	NV(2.0G) < NV(2.1)

so once we get to 2.1, the "-current > point release" inequality
is going to fail.

I see two ways to fix this.   Either make the point releases
go back to being 2.0.1 2.0.2 ... (it is irrelevant whether the
next major release is 2.1 or 3 in this scenario), or find a
way to redefine the way __NetBSD_Version__ is constructed so that
the inequality goes back to being true again.   Obviously this
only needs to be done for future values of __NetBSD_Version__
(as long as we end up with a value > 200000000 of course).

Whether or not we need to worry about 2.0[A-G] and their
__NetBSD_Version__ values I'll leave it for someone else to
worry about.

The point of this message is just to make sure this issue has been
considered before 2.0 is completely frozen and distributed with
documentation saying what release is going to come next - just in
case that needs to alter.

kre