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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 14 Jul 2008 21:31:29 -0500
From:	"Stoyan Gaydarov" <stoyboyker@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
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, Jul 14, 2008 at 9:22 PM, Linus Torvalds
<torvalds@...ux-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
>
--
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/