On Thu, 24 Apr 2003, Frederick Bruckman wrote:

> On Thu, 24 Apr 2003, Greywolf wrote:
>
> > This is not how I read it, which was:
> >
> > 2.0 gets released, -current becomes 2.1A, next release is 2.1...
> > 2.1 gets released, -current becomes 2.2A, next release is 2.2....
> >
> > This is exactly backwards from what we have now.
>
> That's the way I parsed the proposal, too, and I don't see how that's
> any clearer to users. Worse, it means you'd have to mask and do

It's clearer in that at any one time, "2.1" is either used in current
("2.1A", "2.1B", etc..) or in a release ("2.1", "2.1.1", etc...). That way
we won't have confusion about "upgrading" from 1.6R to 1.6.1.

> arithmetic on __NetBSD_Version__ to get anything useful out of it.

Uhm, why?

Yes, the current way we arrange bits & digits won't work, but there's no
reason we need to (nor should, really) stick with an arrangement that
doesn't work well for us. If we do this, we can and should change the
digit arrangement to be something that works well.

Also, since we're looking at 2.0 as the next release, this'd be a great
time to change it. :-)

> > Anything with a .0 in the fourth place (i.e. null third and/or fourth
> > digits, 1.6, 1.6.1, 2.0, 2.0.1...) would be considered a release, while
> > -current would be, for 2.0, 2.0.0.1, 2.0.0.2, 2.0.0.3, etc. , and then
> > we release 2.0.1 or whatever, at which point -current turns into
> > 2.0.1.[1..n].
> >
> > Or Did I Miss Something, Here? [TM]
>
> That represents things as exactly backwards from the actual state of
> affairs, as if current derived from a branch, rather than vice-versa.

Yes, that idea would be poor since current just before 2.0.1 (2.0.0.12
say) is technically more modern overall than 2.0.1, which is the next
higher number.

> Of all the proposals, the only one that improves on the current
> one (IMO), is to *not* bump uname, and let LKM's get their needed
> information some other way.

That would work, but then we'd need to come up with a way to name kernel
and current versions.

Take care,

Bill