Re: (Short?) merge window reminder

[porpen]

Hi,

On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.

With all the discussion about matching the year, keeping the numbers smallish and breaking build/test scripts...

Why not match the year this way: v2.11 = 2011

So, to get there, how about: 
v2.6.39 current
v2.6.40 
v2.7.?  (see below)
v2.11.0 sometime this year maybe or skipped.
v2.12.? early 2012.
v2.13.? early 2013.
and so on...

To hell with making the months match up to anything.  IMHO, that's micromanaging BS that will cause recurring troubles forever.

Advantages: 
 -Build & test scripts won't break for a while. (see note about this below)
 -Major and Minor numbers together approximately match the year of release.
 -Subreleases don't get too big. e.g. with 2 week releases, v2.12.x might reach .26 or .27 and resets with v2.13.0 

Disadvantages:
 -in the year 2100 the version will have to leap to v21.0 and that numbering will last until v29.99 or so.
 -most of us won't live long enough to see v31.14 or v42.0

The build scripts would finally break in the year 25500 with the step after kernel v254.99.?.  I suspect one of our decendants in the next 23.5 thousand years can figure out how to fix that.

IMHO, this may be a least effort compromise between the keep-numbers-small camp, the match-the-year camp and the don't-break-scripts camp.

Of course, math junkies like me would love to see v2.7.18.28 at some point in the process.  Could we jump straight to that just before we leap to v2.11.0 or whatever numbering is chosen please?

-phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/