On Thu, 24 Apr 2003, Bill Studenmund wrote:

> On Thu, 24 Apr 2003, Frederick Bruckman wrote:
>
> > On Thu, 24 Apr 2003, Greywolf wrote:
> >
> > > 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?

As versions currently map to __NetBSD_Version__:

	2.1	=>	201000000
	2.1.1	=>	201000100
	2.1A	=>	201010000
	2.1B	=>	201020000
	2.2	=>	202000000

This shows that the activity on the trunk is more significant than the
activity on a branch, and lets you test for most feature changes,
those that appear only on the trunk (and of course, the next branch),
with a simple comparison.

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

You keep saying that, but maybe I'm too thick to get it. So, can you
tell us what arrangement of digits would make __NetBSD_Version__ for
2.2A and 2.2B less than for 2.2?

Frederick