Bill Studenmund wrote,
>Well, what technical criteria do we have for the version number? Its
>primary purpose is to communicate a version of the kernel. Since we don't
>have any other version numbers around, we also use it to version the whole
>os.
The notion of versioning the entire OS based on the kernel changes never did
sit too well with me. My personal perference is the AIX or Solaris method of
versioning each component/package of the OS including the kernel. The gulf
between userland and kernel is great enough to where it is helpful to know that
the archive utilites are at 1.0.54 and the kernel is at 4.3.3.86.

>We can thus know that
>version 1.6Q is higher (newer) than 1.5Y or 1.4G. We also know that 1.6.1
>is higher than 1.6 and 1.5.3 and 1.4.2.

I do like the current idea of having letters for -current since there is a 
sequence. It also keeps the informality of development by suggesting that only
the numbers releases are formal stable builds. As suggested, the third digit
can throw mess into the works because of ignorance of the versioning strategy.

>Here's yet another way to get out of the mess. Add a null zero to our
>release numbers. So 1.6 becomes 1.6.0, and 1.6.1 becomes 1.6.0.1. The
>latter is more accurate in terms of features, and this scheme would
>reflect how the digit positions in the __NetBSD_Version__ define are used.
>It would look poor for marketing, but folks wouldn't be as likely to
>wonder if 1.6N is newer or older than 1.6.0.1...

This idea of labelling the stable releases as a fourth digit has merit. It can
be extended to say that the third place could be a spot for the -current
version as well. If 1.6.0.1 is the stable release, 1.6.B.0 could be current. It
would suggest that 1.6.0.1 is a lower version of 1.6, but that the B infers 
something "wierd" or "unstable" about the release. Since there is a placeholder
value after the B, that space could be used to more finely grade the releases
of the current mainline. As a matter of upgrades, the system would suggest that
one could upgrade to B, but that fallback may have problems.

By using a third and fourth placeholder, the information in sys/param.h might
have to be altered slightly, but just enough to get the point across. The
state of it now could accomodate this new versioning scheme. 

As an aside to this, is there any thought about versioning the userland 
programs in the same way? Is it possible to have the games set as 1.6.0.2
in cases where some programs had to have bug fixes? I think it might help the
casual user keep his system patched without having to work at compiling a 
-current to get a simple fix.

-Andy Wallis