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]

Date:	Tue, 15 Jul 2008 18:24:44 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stoyan Gaydarov <stoyboyker@...il.com>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: From 2.4 to 2.6 to 2.7?

[Linus Torvalds - Mon, Jul 14, 2008 at 07:22:04PM -0700]
| 
| 
| 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
| 

Hi to all! Since I've been Cc'ed :) I think I'm not the right person
to be asked about numbering scheme (and since I'm not that long in
kernel) BUT actually I think there is only one question - it's not
about how to number the kernel but rather what we trying to say by
numbering scheme. Some areas should be distinguished:

	- development/stable team
	- distros
	- regular users

Most developers work with git trees and rather carries about sha1 then
a version number :) So eventually numbering scheme is not that important
for developers by its own.

Distros - well, i think distros use they own scheme anyway so they don't
really care about kernel versioning scheme (Gentoo-2008, Fedora-9, Ubuntu-8.04...)

So we have the quite large group of people which should be considered for
convenient versioning scheme - _regular users_. Lets say I'm a regular user -
the most convenient scheme for me would be YYYY.r.s i think since it tells
me - this kernel is fresh enough to be used on my shining laptop, and maybe
it even supports all hardware I have! And at least it looks good -

	Linux-2008.0.0

but personally i don't really care that much :)

		- Cyrill -
--
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/