On Sun, Dec 05, 2004 at 03:21:35PM +0100, Johnny Billquist wrote:
> [...]
> >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.

Exactly.

> 
> [...]
> >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.

Yes, the old scheme worked, and didn't break because 1.7 was not called 1.7
but 2.0. It breaks because it was decided that the next release of the
2.0 branch won't be called 2.0.1 but 2.1. And when this decision was made
we didn't notice that this would cause problems with the way -current
is named (and the way it translates to __NetBSD_Version__), this is why
-current's name was changed at a later time.

> 
> 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.

I'm not sure if you means x.0 in the new scheme, or x.0 in the old scheme
here. If the first, x.0 is what was x.y.0 in the old scheme so nothing changes
here. If the second, then this has no grounds, as there was no separate
branches for developements of x.y and x+1.0

> 
> >>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 

And so some considered that 1.6 should have been called 2.0, others
thinks that we're still not quite there (we don't have SMP on all supported
archs yet, and in 2.0 threads of a single program won't use more than one
CPU, the scheduler would require some serious changes to really be SMP-aware,
etc ...). 

> 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.

Yes. Unfortunably it was not noticed before.

> 
> 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. :-) )

It would have worked too.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--