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: <20081018073810.GA7182@isilmar.linta.de>
Date:	Sat, 18 Oct 2008 09:38:10 +0200
From:	Dominik Brodowski <linux@...inikbrodowski.net>
To:	"H. Peter Anvin" <hpa@...nel.org>
Cc:	Greg KH <greg@...ah.com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: 2.6.28-rc1 --> 2.8.0-rc1; 2.6.27.y --> 2.6.28 [Re: [RFC] Kernel version numbering scheme change]

On Sat, Oct 18, 2008 at 12:18:58AM -0700, H. Peter Anvin wrote:
> Greg KH wrote:
> >>
> >>I think it's both visually cumbersome and has the problem that it is 
> >>harder to predict future releases.  The first problem can be dealt with 
> >>by simply subtracting 2000 from the year (Altera uses this scheme for 
> >>their EDA tools, and I didn't realize it for quite a while because it 
> >>looked so natural), but the second is still a problem.
> >
> >What is the "problem" of predicting future releases?  What relies on the
> >actual number being "correct" some random time in the future?
> >
> 
> We already have the 2.6.28-rc series; and we are already talking about 
> 2.6.29 features.

Well, Linus hasn't yet changed SUBLEVEL or EXTRAVERSION[*]. But Adrian has
already stated that he will support what is known as 2.6.27 for a long time.
What about Linus naming the next release 2.8.0 (and move on with 2.8.1,
2.8.2, ... with no special meaning to the numbers), so instead of 2.6.28-rc1
it's 2.8.0-rc1. And once Adrian takes over from the -stable team, he could
release 2.6.28, 2.6.29 and so on when he thinks a new minor number is
appropriate, such as Willy intends to release 2.4.37.

Best,
	Dominik


[*] Actually, it might be helpful if the very first commit after a
release were to change SUBLEVEL to the next number and EXTRAVERSION to "pre"
or something else, so that /lib/modules/2.6.y/ and the initramfs isn't then
overwritten by the sometimes rough builds between 2.6.y and 2.6.(y+1)-rc1.
--
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