July 28, 2008
July 16, 2008
From 2.4 to 2.6 to 2.7?
Linus对未来linux kernel版本号命名的想法
from Stoyan Gaydarov
to linux-kernel@vger.kernel.org
cc torvalds@linux-foundation.org,
Alan Cox
gorcunov@gmail.com,
akpm@linux-foundation.org,
mingo@elte.hu
date Tue, Jul 15, 2008 at 10:10 AM
subject From 2.4 to 2.6 to 2.7?
mailing list
mailed-by vger.kernel.org
hide details Jul 15 (2 days ago)
Reply
Filter Assistant
First things first, I would like to know what prompted the change from
2.4 to 2.6 kernels. I know that the change had to do with the
development version, the 2.5 tree and the massive amounts of patches
distros had to carry. Aside from this i think it was also the
scheduler changes that prompted the 2.6 version, but I don't know all
that much about it and any other comments about the change would be
great.
Second I wanted to talk about the linux 2.7.x kernel, whats in the
making or maybe even not started, that could prompt a change to a 2.7
version kernel, i know that a lot of good changes are going into the
kernel as part of the rcX kernels in the 2.6 version. Would we
continue to see 2.6 kernels until some big problem shows its head and
we all go "oh sh**" and then change something so massive that it
prompts the change or are we going to continue with the 2.6 tree. I
just want to get some information and peoples opinions on this, just
to see where things are headed.
-Stoyan G
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reply
Reply to all
Forward
Linus Torvalds
to Stoyan, linux-kernel, Alan, gorcunov, akpm, mingo
show details Jul 15 (2 days ago)
Reply
Filter Assistant
On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
>
> Second I wanted to talk about the linux 2.7.x kernel, whats in the
> making or maybe even not started
Nothing.
I'm not going back to the old model. The new model is so much better that
it's not even worth entertaining as a theory to go back.
That said, I _am_ considering changing just the numbering. Not to go back
to the old model, but because a constantly increasing minor number leads
to big numbers. I'm not all that thrilled with "26" as a number: it's hard
to remember.
So I would not dismiss (and have been thinking about starting) talk about
a simple numbering reset (perhaps yearly), but the old model of 3-year
developement trees is simply not coming back as far as I'm concerned.
In fact, I think the time-based releases (ie the "2 weeks of merge window
until -rc1, followed by roughly two months of stabilization") has been so
successful that I'd prefer to skip the version numbering model too. We
don't do releases based on "features" any more, so why should we do
version _numbering_ based on "features"?
For example, I don't see any individual feature that would merit a jump
from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
should be done by a time-based model too - matching how we actually do
releases anyway.
So if the version were to be date-based, instead of releasing 2.6.26,
maybe we could have 2008.7 instead. Or just increment the major version
every decade, the middle version every year, and the minor version every
time we make a release. Whatever.
But three-year development trees with a concurrent stable tree? Nope. Not
going to happen.
Linus
3G iPhone's Battery Life Beats AT&T Rivals--But EvDO BlackBerrys Run Longer
