Re: [RFC] Kernel version numbering scheme change

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Friday, 17 of October 2008, Greg KH wrote:
> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > And that's my point here, do we want to change the current numbering
> > > scheme as people have expressed annoyances of the current one.
> > 
> > But any new scheme will be just as annoying to someone and it messes up
> > existing documentation, understanding and risks breaking third party
> > tools.
> > 
> > Is it really worth the hassle, plus we'll have to change again if we use
> > date/times because once we are shipping Linux out to Alpha Centauri with
> > colonists there will be serious problems trying to compute the effect of
> > tau on release numbering ...
> 
> Sure, but by then, the 2.6.521 release will be out and we could fix it
> up by finally going to 3.0 :)

Surely some scripts will start to break as soon as the third number gets
three digits.

> Seriously, am I the only one that is getting annoyed by our version
> numbers?  If so, I can live with it, but I got the feeling that I wasn't
> alone here.

Actually, I thought we could continue to use a w.x.y.z numbering scheme, but
in such a way that:

w = ($year - 2000) / 10 + 2 (so that we start from 2)
x = $year % 10
y = (number of major release in $year)
z = (number of stable version for major release w.x.y)

Then, the first major release in 2009 would be 2.9.1 and its first -stable
"child" would become 2.9.1.1.  In turn, the first major release in 2010 could
be 3.0.1 and so on.

This seems to be close enough to the current numbering so that nothing should
really break.

Thanks,
Rafael