Subject: is __NetBSD_Version__ being misused (again) ?
To: None <tech-kern@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 08/31/2007 19:34:08
I see that for NetBSD 4.0_BETA2 __NetBSD_Version__ has been
set to 400000003

That's incompatible with the comments earlier in param.h ,,,

 *      #define __NetBSD_Version__ MMmmrrpp00

The last two digits there are 00 (apparently always), which
of itself would be no great problem, but raises the question
of just what __NetBSD_Version__ is going to be when NetBSD 4.0
is finally released?

That would normally be expected to be 400000000 (compatible
with NetBSD 2.0 and NetBSD 3.0 and the post 1.6Z style
numbering), but now cannot be, or 4.0 < 4.0_BETA2 which
makes no rational sense.

Surely beta releases should have the same version id as the final
release, after all, they're supposed to be functionally identical
(just a way to remove any remaining bugs before the release).

Do we know what value __NetBSD_Version__ is likely to have in the
released 4.0, or will it simply depend upon how many more bugs get
fixed?  Or perhaps a solution might be to simply skip a 4.0
release and move directly to 4.0.1 (when the beta process finishes)
that would work around the number sequencing issues.  Of course,
it would screw the "prepare binary LKM" people...

How is the __NetBSD_Prereq__() macro supposed to function in
this new world of arbitrary __NetBSD_Version__ usage ?   That is,
how should one use __NetBSD_Prereq__ to require NetBSD 4.0 ?

kre

ps: I did see the brief discussion (last November) about possibly splitting
the ABI and uname -r version identifiers, but nothing seems to have
happened about that.   It wouldn't be relevant here anyway, as it was
the ABI version that was bumped (and apaprently needed to be), which is
the one that matters (the other is just noise).

I also saw the HEADS UP from Feb when a __NetBSD_Version__ bump for
the netbsd-4 branch was justified, but no mention of the consequences,
and no apparent further discussion or lead-in discussion?  That seems
(if I read line 1 cvs/rcs date comments correctly) to have been well
after 400000000 turned into 400000001 and later 400000002, which seem
to have happened without any discussion (or even mention?) at all.