Subject: Re: NetBSD version naming - suggestion
To: Frederick Bruckman <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 04/24/2003 14:11:27
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