Re: [RFC] Kernel version numbering scheme change

From: david
Date: Fri Oct 17 2008 - 21:23:59 EST

On Sat, 18 Oct 2008, Rafael J. Wysocki wrote:

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

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.

we've had three digit numbers in the third position before (2.3 and 2.5 went well past three digits IIRC)

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 In turn, the first major release in 2010 could
be 3.0.1 and so on.

if you want the part of the version number to increment based on the year, just make it the year and don't complicate things.

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at