On Sun, 5 Dec 2004, Manuel Bouyer wrote:

> On Sun, Dec 05, 2004 at 02:35:32PM +0100, Johnny Billquist wrote:
>>>> Personally, I can't understand how that reasoning came about. It wasn't a
>>>> problem in 1.x, so why was it suddenly a problem in 2.x?
>>>
>>> because we dropped a digit in the numbering scheme.
>>
>> I'm not sure I follow here. I assume we mean the same when you say digit,
>> and I say number.
>> Which number did we drop? I believe __NetBSD_Version__ have the same
>> number of digits as before, so we're just talking about version numbers we
>> print out.
>
> Yes. But the digits in __NetBSD_Version__, and their positions in this
> number, is directly related to what we print out.

Yes. And the format of that macro have not changed. No digits have been 
dropped. Just the interpretation of them. Some digits will now always be 
zero in __NetBSD_Version__. That's what have happened.

>> We previously had major.minor.patch for releases, while we had
>> major.minor<letter(s)> for current.
>> Now we have major.minor  -- don't we have any patches anymore?
>
> No exactly. we now have major.patch. major was useless because it was
> never changed (well, only once, and because minor was at 9). So minor became
> major.

That's part of what we're arguing. :-)

> Well, to be really correct the new scheme allows major.patch.security-patch,
> (we didn't have security-patch before), but only if necessary. We can't
> tell if there will be a 2.0.1 or not.

So basically, we still have the same format for the version number for 
official releases. What have changed is perhaps the rule about when to 
make a new major release.

The only (and big) change is how to number -current. And we have 
definitely not dropped any digits there. We have, if anything, added. What 
was 2.0H suddenly became 2.99.10 (or if it was 2.99.9).

>>>> Current should have been named 2.0<letter> until 2.1 came out, at which
>>>> time, current should carry on as 2.1<letter> if we had stuck with the old
>>>> scheme.
>>>> Why on earth did people suddenly think that current should always be
>>>> 2.0<letter>???
>>>
>>> because a digit was dropped in the numbering scheme.
>>
>> Why would that prevent a 2.1<letter>?
>
> because 2.1 won't be derived from current, but will be a tag in the netbsd-2-0
> branch (right, we should have dropped a number here too - netbsd-2-0
> should have been called netbsd-2).

But in the old numbering scheme, 2.1 would be derived from -current. So it 
would work just fine.

Like I said, there must be something I'm missing, because the old version 
scheme worked, and it didn't suddenly stop working just because 2.0 came 
out, yet that's the argument for changing the numbering scheme of 
-current that I've seen.

Patches to 2.0 would previously be called 2.0.<number>, which were derived 
from 2.0. Current would be 2.0<letter> until 2.1 was released, at which 
time current would switch to 2.1<letter>.

>> It might not have more features either, it all depends on how current you
>> -current is.
>
> Yes. But in any case it won't have less.

True, if no new features are ever introduced within a major version.
But that will once more get us back to having major releases pretty often. 
That is a matter of personal opinion, but I think doing a new "major" 
release every year is too much. And then we have the silly point of some 
people to never run something called x.0, but always wait for x.1 for the 
big bugs to be rooted. I wonder what they will think when NetBSD will 
release so many x.0 versions.

>>> The real motivation was to drop a digit in the numbering scheme, which
>>> required to bump the first digit, and the new features could also
>>> justify this.
>>
>> In my world that's an after-the-facts construct, since I so clearly
>> remember the talk about 2.0 long before any discussion about a new version
>> numbering scheme came up.
>
>> From what I remember it was not. But the discussion I'm refering to,
> from which the decision was made, was on the -developers mailing list.
> If you're refering to the 2.0<letter> to 2.99.<number> switch for current,
> yes it came later, but as a consequence of the new numbering scheme for
> releases, because of a problem we didn't notice before with
> __NetBSD_Version__

As I remember, it's more split up than that. I can't remember any big 
discussions about when/if a swtich to 2.0 should be, just that it seems 
like a consensus that when SMP was working, we should. But a discussion 
had been off- and ongoing aboout the version numbering of -current for a 
long time. Some people thought that 1.6A was like a alpha release for 1.6, 
and so was before 1.6, and not after. That had occasionally caused 
confusion, especially for people new to NetBSD. Most however seemed to be 
of the opinion, once they got accustomed to it, that is was a good scheme. 
But the discussion about whether it was good or not carried on.
When 2.0 became imminent, someone started claiming that the current way of 
numbering -current would not work when 2.0 was released, and after that it 
was decided to change the numbering of -current.

I suspect I must have missed the decision that the minor version number 
should be skipped, which might explain my confusion. For if the minor 
release number is skipped, then the new version numbering scheme makes 
more sense. (The alternative then would have been to call -current 
2<letter> I guess. :-) )

 	Johnny

Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol