Date:        Sun, 18 Nov 2007 00:43:29 -0800
    From:        "Trevor Talbot" <quension@gmail.com>
    Message-ID:  <90bce5730711180043y185c6206qabc95174c1c7c43f@mail.gmail.com>

  | If you know you want to run specifically on the released version of
  | 4.0.0, why would you not use whatever value it actually has on 4.0.0,
  | regardless of what that value may be?  That's what I meant about
  | locking to a specific version.  You can't test compatibility by
  | guessing at an interface you don't have access to...

The point is that you sometimes know that function X existed, and had
3 parameters from NetBSD 2.0 until NetBSD 3.1, and you want to write
code that compiles for all of those versions (most likely including
unreleased minor versions of NetBSD 2 as the interface isn't likely
to change in that now) - but not for newer NetBSD 3's or for 4 (etc)
(and not before NetBSD 2).

And while testing for specific versions is possible, as we know what
value __NetBSD_Version__ had in each of those, if we want to do more
general tests, some macro (be it __NetBSD_Prereq_() or something else)
is better, as it allows the macro to deal with the internal structure
(such as it is) of __NetBSD_Version__ - allowing that to be altered
if necessary (as in the switch from 2.0I to 2.99.8 or whatever it was).

In any case, whatever is appropriate - changing __NetBSD_Version__ before
4.? is released, or deleting the macro, or altering its usage to include
another parameter, or altering the specification of how __NetBSD_Version__
should be used, something should be done before 4.0_RCx gets the RCx
removed from its name (at the very least to allow LKM builders, and others
to have LKM's built properly for the released version).

This coming release is the first one where __NetBSD_Version__ isn't
(currently) set according to its specification - the "(again)" in the
Subject relates to the state of it in the 2.0I versions after it was
determined that 2.1 would be what would have been 2.0.1 in the previous
naming scheme, and 3.0 would be the next major release (ie: that time it
only affected -current which is much less serious than a real release).

kre