On Wed, 23 Apr 2003 keks@kibla.org wrote:

> > Yes, that's what we have now. And having something that makes sense the
> > first time you encounter it is what I think we should strive for.
>
>
> about the cool stuff -> get linux
> about the arch only in -current -> get to know NetBSD, try hard and
> eventually contribute experiences

That's exceedingly simplistic. Among other things, you're implying that
there's no cool stuff for NetBSD, which I know is wrong. :-)

> no, seriously: under no circumstance we should attract too many users
> to NetBSD. Why should we? it is the quality (knowledge and readiness

There's a huge gap between not turning folks off of NetBSD and turning
into the be-everything that Linux is.

The point isn't to "attract too many users," it's to not drive away the
ones who have tried us. :-)

> to learn) of our users that makes the NetBSD the best. if we try to
> be easy to do that and easy to do that ... i don't want a system like
> that. I like the stripped, configurable, powerful, logical system that
> doesn't do things for me, instead of me or behind my back. It should
> do exactly what i want. Sure it should enable me to restyle it and make
> a first-contact-all-automated-multi-media-user-friendly os out of it.
> but that should by no means be the default.

Uhm, how did we get from a version numbering scheme that makes intuitive
sense to new users to a first-contact-all-automated-multi-media-user-
friendly os?

> That said back to the theme. ===> sure we want people to join the project
> since there is no project without users and developers. but i think we
> have out niche (hope that the word is right), and it is technical
> excellence not user-friendliness.
> So back to the original conversation: If the current scheme fulfills
> tehnical criteria, there is no need to change it (especially not for
> the reason of new users feeling more comfortable with it).

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.

We choose to use numbers, as opposed to names, so that we can also convey
an ordering. We use a time-increasing sequence. 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.

The problem is that at first glance the scheme implies you can compare
1.6M and 1.6.1. You can't. And that's the problem. The scheme propogates
confusion to those that think they understand it but don't.

So on its ability to communicate kernel and os versions, the current
scheme fails. So technically it doesn't fulfill its requirements.

Hmmm...

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...

Take care,

Bill