Subject: Re: Version Naming/Numbering
To: Robert Elz <kre@munnari.OZ.AU>
From: Bill Studenmund <email@example.com>
Date: 09/17/2004 14:07:06
Content-Type: text/plain; charset=us-ascii
On Fri, Sep 17, 2004 at 06:48:44PM +0700, Robert Elz wrote:
> My concern is upon the way it all affects __NetBSD_Version__ (from
> 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.
> 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.
I thought after the 2.0 release we were going to move current's version so=
that we didn't have this problem. I've forgotten what the exact fix was,=20
but I know there are a few ideas floating around. I don't remember if it=20
was we were going to 2.9 or 2.99 or we were going to 3F & friends and=20
arranging it so that NV(3.0) > NV(3F).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----