Re: From 2.4 to 2.6 to 2.7?

["Stoyan Gaydarov" <stoyboyker@gmail.com>]

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
>