Subject: Re: NetBSD version naming - suggestion
To: NetBSD Current Users <email@example.com>
From: Peter Eisch <firstname.lastname@example.org>
Date: 04/24/2003 17:00:32
I know the scope is clearly different, but for a moment I thought I was
reading old mail on the perl list about versioning. With that in mind,
perhaps the odd sub-versions should be -current revs where the even
sub-versions are releases.
Again, not trying to muddy the waters, just noting the potential analogy.
on 4/24/03 4:11 PM, Bill Studenmund at email@example.com wrote:
> 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,