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 10:07:21 -0400 (EDT)
From:	Byron Stanoszek <bstanoszek@...time.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>,
	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, Linus Torvalds wrote:

> 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.

Well, we just haven't had anything big enough to merit an increase in the
minor number lately. I nominate the removal of the BKL as one such feature,
based on the sheer work required and how many modules you'll need to touch to
do so. In fact, it would be the natural conclusion to a 2.x series that
highlighted SMP as its primary new feature.

But it's hard now to predict future milestones, or when an overall paradigm
shift might happen. In those cases you'll want to give Linux a bright new
announcement to the world, instead of it being "just another standard year of
kernel development".

Remember, you used to have versions called 1.3.100 before -- and they seemed
perfectly normal back then. I personally like how we're still on 2.y.z numbers
compared to all of the other OSes (Solaris 11, HP-UX 11)...it makes Linux still
feel young, showing how much better it can get ;-)

So I vote for releasing by "features" still, and keep the current numbering
scheme. Who knows when the next big idea will pop up that's worthy of 3.0.0.

  -Byron

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