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: <pk4gf4p0nuidil37alro57l2a9ocabuvtr@4ax.com>
Date:	Fri, 17 Oct 2008 15:26:24 +1100
From:	Grant Coady <gcoady.lk@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	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 Thu, 16 Oct 2008 21:02:39 -0700, you wrote:

>On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
>> On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
>> You miss the best alternative:
>> 
>> Simply keep the status quo.
>
>I'd argue that is is a pain.  Linus has expressed frustration with the
>current numbering scheme, and as someone who deals with kernel version
>numbers every single day, I too am mildly frustrated.
>
>I think the main reason why is just that small numbers are easier to
>keep track of in your mind.  As we are ever increasing the version
>number, the release numbers feel like they are getting closer together,
>making them less distinguishable.
>
>For example, think of the following:
>	2.6.5 vs. 2.6.9
>Your mind focuses on the 5 and 9, and in thinking about them, it is much
>easier to keep them apart.
>
>Now, try the same with:
>	2.6.24 vs. 2.6.27
>You are repeating the tens digit, the "two", so it is a bit harder to
>distinguish things.  After a few years of this, it gets more difficult
>
>So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
>track of, and the release number is a small one, making it too easier to
>track and distinguish from each other:
>	2009.1 vs. 2009.5
>or
>	2010.2 vs. 2011.5

So add a 'RELEASEDATE = 2008-nn-nn' on line five of the top Makefile 
just under the 'NAME = Rotary Wombat' variation.

Perhaps lose the leading '2.6.' when 2.6.30 comes around, give some 
warning to all that their scripts are gonna break with that release.  

Then you could play with low 3.0.0 numbers again :)

Grant.

>It also means something that lets you remember back to what was going on
>for that release better, if you can easily place it within a specific
>time frame, which is important for those of us who work with different
>kernel versions all the time for different projects and backports and
>stable releases.
>
>If the number stays the same, my feeble brain will survive and I'll just
>rely on my huge spreadsheet of when specific kernels were released when
>to get along, and hopefully I will not make any more .26.5 releases when
>I mean .25.5 and such like I have in the past :)
>
>thanks,
>
>greg k-h
-- 
http://bugsplatter.id.au
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ