Messages in this thread | | | Date | Mon, 14 Jul 2008 21:31:29 -0500 | From | "Stoyan Gaydarov" <> | Subject | Re: From 2.4 to 2.6 to 2.7? |
| |
On Mon, Jul 14, 2008 at 9:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > 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. I would also recomend staying away from the old model
> > 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. The main reason I asked these questions is because we have 2.4.36 and 2.2.27 and those are pretty high numbers, so I thought maybe we would start 2.7.x releases just so that they start back at 1 > > 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. Does it have to be even numbers only?
> > 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. I dont think people would agree with the 2008.7 version numbers although it would make them more aware of how old the kernel and prompt them to upgrade > > But three-year development trees with a concurrent stable tree? Nope. Not > going to happen. > > Linus >
| |