Re: [RFC] Kernel version numbering scheme change

[Greg KH <greg@kroah.com>]

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