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: <20081017174052.GD2221@kroah.com>
Date:	Fri, 17 Oct 2008 10:40:52 -0700
From:	Greg KH <greg@...ah.com>
To:	"Giacomo A. Catenazzi" <cate@...eee.net>
Cc:	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:46:27PM +0200, Giacomo A. Catenazzi wrote:
> Greg KH wrote:
>> We number the kernel based on the year, and the numbers of releases we
>> have done this year:
>> 	YEAR.NUMBER.MINOR_RELEASE
>> For example, the first release in 2009 would be called:
>> 	2009.0.0
>> The second:
>> 	2009.1.0
>> If we want to be a bit more "non-zero-counting" friendly: we can start
>> at "1" for the number:
>> 	2009.1.0 for the first release
>> 	2009.2.0 for the second.
>> Then the stable releases can increment the minor number:
>> 	2009.1.1 for the first stable release
>> 	2009.1.2 for the second.
>> 	and so on.
>> Benefits of this is it more accuratly represents to people just how old
>> the kernel they are currently running is (2.6.9 would be have been
>> 2004.9.0 on this naming scheme.)
>> Yes, we can handle the major/minor macros in the kernel to provide a
>> compatible number so that automated scripts will not break, that's not a
>> big deal.
>> Any thoughts?
>
> What about:
> - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?

Sure, what's the big deal?

> - a stable version in January of a kernel released in December
>   still has the old year? (I hope yes, but it could confuse users.)

stable versions would not modify the year.

> - when (if) we need a big innovative (or incompatible) kernel
>   change, how to mark old and new kernels?

Based on our current development model, this isn't an issue.

thanks,

greg k-h
--
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/