Re: From 2.4 to 2.6 to 2.7?

[Stefanos Harhalakis <v13@v13.gr>]

On Sunday 20 July 2008, Rene Herman wrote:
> On 19-07-08 22:49, Craig Milo Rogers wrote:
> > On 08.07.19, Rene Herman wrote:
> >> Really, find me a single Linux developer who wouldn't try just a little
> >> bit harder for a big 3.0 release. This is still a community, not yet a
> >> boring office schedule...
> >
> > 	I'm afraid that the allure of 3.0 would mean that everyone
> > would want to get their shiny new subsystem/scheduler
> > rewrite/bootstrap file format change/whatever incorporated into it,
> > resulting in a protracted integration period and an unstable system.
> > According to this line of thought, Linus should simply announce
> > version 3.0 with no forewarning...
>
> Or better yet, we'd have 342 -rc's and a REALLY big party when 3.0
> finally hits the streets.

I suggest that major and minor versions follow some milestones (as suggested 
to a message that I cannot reply directly). For example:

Starting from 'today', mark all open bugs and change version to 2.7 when all 
those bugs are closed. Then mark the open bugs of that time and change to 2.8 
when those bugs are fixed. Repeat as needed.

Set a 'target'/goal and change version to 3.0 whenever worldwide linux 
server/desktop percentage reaches XX%. (Of course this may happen before 
changing to 2.7 but this is not a bad thing (tm)). Then set another target 
(that may not be related to linux adoption) etc, etc...

This will keep the current versioning scheme, set some common goals for all 
developers, add more meaning into trying to fix bugs and prevent the world
from experiencing large linux version numbers.

As a side-effect, setting targets like those may make the whole community 
cooperate even more/better by having common long-term goals.

...

p.s You could also keep the X.Y.Z notation and change the major version
number whenever the way of versioning changes (and the current one is
actually version 2) :P