Date:        Thu, 23 Sep 2004 07:56:33 +0200
    From:        Matthias Scheler <tron@zhadum.de>
    Message-ID:  <20040923055632.GA13699@colwyn.zhadum.de>

  | On Wed, Sep 22, 2004 at 03:36:58PM -0700, The Grey Wolf wrote:
  | > I see the push for advancing major numbers as totally arbitrary and bogus.
  | 
  | Perhaps you should have a look at the archive of various NetBSD mailing
  | lists? You'll find various examples where people are really surprised
  | that e.g. upgrading from 2.0G to 2.0_BETA doesn't work becaues it is
  | a downgrade and not a upgrade.

You're actually confusing two unrelated issues (unrelated, but related...)

One is what -current should be called (2.0G or 2.99.7) and that's the one
you're talking about above.

The other is whether the next major release after NetBSD2 should be 2.1
or 3.0 - I don't think this one has any possible technical arguments one
way or the other, it is all just about perceptions of what is best.
(That's what GreyWolf was commenting on).

But while people are continuing arguing about noise like this, we still
have -current with __NetBSD_Version__ set to a value that is less than
the value for __NetBSD_Version__ for 2.1, which is not good if 2.1 is
to be the next patch release, and not the next major release.

What the system ends up being called at a human level isn't very
important (whether 200990700 is 2.99G or 2G or 2.0G or 2.99.7).
But getting __NetBSD_Version__ set to a reasonable value quickly
is important.

That, or if we really do want to "break code that depends upon
version numbers" then simply delete __NetBSD_Version__ from param.h
completely.

Unless we're doing that though, someone please decide what value for
__NetBSD_Version__ -current (as it is today) should have, and set it
to that - soon!

While I have (had) a script that converts between __NetBSD_Version__
and the human visible format (uname -r) I don't think anyone else does,
so just changing __NetBSD_Version__ should be safe and harmless.
The scripts that currently are used to synchronise the couple of different
places that use this info in the build process, use the comment on the
__NetBSD_Version__ setting to extract the uname -r name and cause it to
be correctly set - it is just fine to leave the comment, and consequently,
what we call the current version of -current, being 2.0G for now,
just fix the numeric value.

kre