>> This is not how I read it, which was:
>>
>> 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
>arithmetic on __NetBSD_Version__ to get anything useful out of it.

not only that, but afaict, it reverses the meaning of a few of the
digits in the __NetBSD_Version)) value.

>> Anything with a .0 in the fourth place (i.e. null third and/or fourth
>> digits, 1.6, 1.6.1, 2.0, 2.0.1...) would be considered a release, while
>> -current would be, for 2.0, 2.0.0.1, 2.0.0.2, 2.0.0.3, etc. , and then
>> we release 2.0.1 or whatever, at which point -current turns into
>> 2.0.1.[1..n].
>>
>> Or Did I Miss Something, Here? [TM]
>
>That represents things as exactly backwards from the actual state of
>affairs, as if current derived from a branch, rather than vice-versa.
>
>Of all the proposals, the only one that improves on the current
>one (IMO), is to *not* bump uname, and let LKM's get their needed
>information some other way.

i think the lkm issue is separate...isn't it?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."