linux-kernel - Re: [RFC] Kernel version numbering scheme change

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: <200810180049.19014.rjw@sisk.pl>
Date:	Sat, 18 Oct 2008 00:49:18 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Steven Noonan <steven@...inklabs.net>,
	Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Friday, 17 of October 2008, Greg KH wrote:
> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > And that's my point here, do we want to change the current numbering
> > > scheme as people have expressed annoyances of the current one.
> > 
> > But any new scheme will be just as annoying to someone and it messes up
> > existing documentation, understanding and risks breaking third party
> > tools.
> > 
> > Is it really worth the hassle, plus we'll have to change again if we use
> > date/times because once we are shipping Linux out to Alpha Centauri with
> > colonists there will be serious problems trying to compute the effect of
> > tau on release numbering ...
> 
> Sure, but by then, the 2.6.521 release will be out and we could fix it
> up by finally going to 3.0 :)

Surely some scripts will start to break as soon as the third number gets
three digits.

> Seriously, am I the only one that is getting annoyed by our version
> numbers?  If so, I can live with it, but I got the feeling that I wasn't
> alone here.

Actually, I thought we could continue to use a w.x.y.z numbering scheme, but
in such a way that:

w = ($year - 2000) / 10 + 2 (so that we start from 2)
x = $year % 10
y = (number of major release in $year)
z = (number of stable version for major release w.x.y)

Then, the first major release in 2009 would be 2.9.1 and its first -stable
"child" would become 2.9.1.1.  In turn, the first major release in 2010 could
be 3.0.1 and so on.

This seems to be close enough to the current numbering so that nothing should
really break.

Thanks,
Rafael
--
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/