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.

Cheers,

on 4/24/03 4:11 PM, Bill Studenmund at wrstuden@netbsd.org 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,
> 
> Bill
> 
>