--OZkY3AIuv2LYvjdk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


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
> sys/param.h).
>=20
> 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.
>=20
> That is, assuming by NV(x) I mean the value of __NetBSD_Version__
> for the release we know as x then
>=20
> 	NV(1.6A) > NV(1.6.n) for any n.
>=20
> But
> 	NV(2.0G) < NV(2.1)
>=20
> so once we get to 2.1, the "-current > point release" inequality
> is going to fail.
>=20
> 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).
>=20
> 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=
=20
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).

Take care,

Bill

--OZkY3AIuv2LYvjdk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBS1H6Wz+3JHUci9cRAr73AJ0X52XY2NtH8abieZdQezl6RR6G7ACfXlnv
+OVWfkgYus4V5LZvb+LAXeo=
=Nw6e
-----END PGP SIGNATURE-----

--OZkY3AIuv2LYvjdk--