On Thu, 24 Apr 2003, Frederick Bruckman wrote:

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

We make one that works.

Here's one example, but we can come up with others.

Since we now will have 2.1A << 2.1, how about:

	2.1A	=>	201000000
	2.1B	=>	201000100
	2.1C	=>	201000200
	2.1[.0]	=>	201010000
	2.1.1	=>	201020000
	2.1.2	=>	201030000

	2.2A	=>	202000000
	2.2D	=>	202000300
	2.2[.0]	=>	202010000
	2.2.1	=>	202020000
	2.2.3	=>	202040000

Yes, this method does have a 1 value difference between the minor digit
and the encoded field. But I don't think we ever decode __NetBSD_Version__
into text, so it won't matter.

The main thing is we keep the values of __NetBSD_Version__ matching the
"newness" ordering.

Take care,

Bill