linux-kernel - Re: From 2.4 to 2.6 to 2.7?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0807141914280.3017@woody.linux-foundation.org>
Date:	Mon, 14 Jul 2008 19:22:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stoyan Gaydarov <stoyboyker@...il.com>
cc:	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	gorcunov@...il.com, akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: From 2.4 to 2.6 to 2.7?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/