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

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

Message-ID: <20081017221430.GA9235@citd.de>
Date:	Sat, 18 Oct 2008 00:14:30 +0200
From:	Matthias Schniedermeyer <ms@...d.de>
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 17.10.2008 14:44, 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.

Personally i could live without the 4 part numbers of the stable series.

When you bump down the third position to second, then fill the third one 
with a dummy/fixed for the "Linus" release, the way is free for stable 
releases that don't feel so stapled to the side.

So with either .0 or .1 for the "Linus" release the next kernel could be:
2.8.0 or 2.8.1
(I would skip 2.7, because it is still perceived as the next development 
Version.)

The stable releases then increment the third number and the next Linus 
release could be 2.9.x because i don't think after 2.8 any skipping of 
uneven numbers would be needed anymore.

In Short: "Back to the roots" with a "good old" 3 part version numbers, 
with stable releases "build into the numbering scheme" instead of 
stapled to the side.




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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