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: <20081018084504.GQ24654@1wt.eu>
Date:	Sat, 18 Oct 2008 10:45:05 +0200
From:	Willy Tarreau <w@....eu>
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 Fri, Oct 17, 2008 at 02:44:09PM -0700, 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 :)
> 
> 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.

No you're not. I am too. Maybe we're both more annoyed than majority
because we're mostly dealing with 4-numbers versions.

I remember having recently suggested someone to test 2.6.37, doing a
confusion between 2.4.37 and 2.6.27. I have already tagged kernels
with wrong versions, having to fix by hand afterwards. It's really
cumbersome some times.

I remember it became really boring in 2.1.X days when X got past 99.

IMHO, having a small number of small digits is the way to go. Using
1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
go to version 4.0. Anyway, there are so many changes between versions
these days that any new versions could justify a major change (eg:
check the size of the 2.6.27 patch).

With versions from 1.1 to 9.9, you can go as high as 88 versions,
which is about 22 years of development at current pace. After that,
we can simply turn to 10.0 and not break anything.

It's also easier for users. Check how many non-kernel techies around you
know all 3 digits of the version they use. It's easier to remember 4.3
than it is to remember 2.6.27.

If we can stick to something like this, we can easily use the 3rd number
for the stable release. We would then have MAJOR.MINOR.PATCHRELEASE and
keep extraversion for -rc etc... The syntax does not change, thus limiting
the breakage and the change in habits.

Regards,
Willy

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