Date:        Fri, 31 Aug 2007 18:57:49 +0100
    From:        Matthias Scheler <tron@zhadum.org.uk>
    Message-ID:  <20070831175749.GA487@colwyn.zhadum.org.uk>

  | Probably 400000003,

In that case you (someone) really need to answer the part of the
message about how the __NetBSD_Prereq__() macro is supposed to work.

If __NetBSD_Version is 400000003 then
	__NetBSD_Prereq__(4,0,0) fails
	__NetBSD_Prereq__(4,0,1) succeeds, but that says 4.0.1 is OK, and
			we cannot possibly know that yet.

The macro simply assumes that the last digits aren't ever going to be
used.  Changing the macro would probably require another version bump...
(as well as being needlessly disruptive).

  | Remember that a year ago we had NetBSD 4.0_BETA which is very
  | different from NetBSD 4.0_BETA2. The version number bump makes
  | sure that you can tell the difference.

Actually, I'm still (now) > a year behind on my NetBSD news in general,
I haven't reached even the first beta announcement yet - but I did kind
of know that.

I'd suggest however that when a release is committed, that is it, no
more incompatible changes.   If the release turns up to have a late
bug that can't be fixed in an API/ABI/LKM compatible fashion, then the
correct response should be to simply abandon the release.

That is, treat the bug and the release like a race condition, in some
circumstances the bug is found before the release, in others only after
the release.  In the latter, the fix is to produce an update release
(go from 4.0 to 4.0.1) and fix the bug.   I'm suggesting that should be
the response in the other case as well - 4.0 was committed, it should
not have been incompatibly altered after that.

So, now as soon as it seems as sure as it ever can be that no more
ABI (LKM) incompatible changes are going to be needed to 4.0_BETA2
increment __NetBSD_Version__ to 400000100 (4.0.1) and make that be
what the (first) NetBSD 4 release is announced as.

kre