(Short?) merge window reminder

Ingo Molnar mingo at elte.hu
Mon May 23 19:01:35 PDT 2011


* Linus Torvalds <torvalds at linux-foundation.org> wrote:

> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.

Yeah, it sounds really good to get rid of the (meanwhile) meaningless
"2.6." prefix from our version code and iterate it in a more
meaningful way.

I suspect the stable team and distros will enjoy the more meaningful
third digit as well: it will raise the perceived importance of
stabilization and packaging work.

Btw., we should probably remove the fourth (patch) level, otherwise
distros might feel tempted to fill it in with their own patch-stack
version number, which would result in confusing "3.3.1.5" meaning
different things on different distros - while 3.3.1-5.rpm style of
distro kernel package naming denotes the distro patch level more
clearly.

I don't think the odd/even history will linger too long: in practice
we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first
year, so any residual notion of stable/unstable will be gone within a
few iterations.

> Because of our historical even/odd model, I wouldn't do a 2.7.x -
> there's just too much history of 2.1, 2.3, 2.5 being development
> trees. But if I do 3.0, then I'd be chucking that whole thing out the
> window, and the next release would be 3.1, 3.2, etc..
> 
> And then in another few years (probably before getting close to 3.40,
> so I'm not going to make a big deal of 3 = "third decade"), I'd just
> do 4.0 etc.

Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks

> Because all our releases are supposed to be stable releases these
> days, and if we get rid of one level of numbering, I feel perfectly
> fine with getting rid of the even/odd history too.

They are very stable releases as far as i'm concerned - i can pretty
confidently run and use -rc2 and better kernels on my boxes these days
and could do so for the past few years.

Thanks,

	Ingo


More information about the dri-devel mailing list