Re: [RFC] Kernel version numbering scheme change

[Grant Coady]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/