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: <ork5c3age1.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Mon, 20 Oct 2008 05:13:10 -0200
From:	Alexandre Oliva <oliva@....ic.unicamp.br>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"H. Peter Anvin" <hpa@...nel.org>, 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: Re: [RFC] Kernel version numbering scheme change

On Oct 20, 2008, "H. Peter Anvin" <hpa@...or.com> wrote:

> Uhm, so what happens when a release starts with an -rc stage intended
> for 2008 release, and then comes out in 2009?

I see at least two possibilities:

- it stays 2008, as originally intended.

- it's labeled 2009 since the beginning of the release cycle

If it gets released in a year other than originally planned, it's no
more confusing that buying a 2009-series car in 2008, or Fiscal Years
vs Calendar Years.

Personally, I'd rather go with the second option than the first, if
nothing else because people seem to like better next year's stuff than
last year's stuff.  But it's not like it matters much.  The point
(AFAICT) is to give some rough guidance of the time-frame of the
release, not something like $(date +%s) of the beginning or end of the
release cycle.

Major might as well be defined as Year+/-1 - Constant, monotonically
increasing.  This should work and make sense as long as no release
cycle takes longer than say a year or two.

> Plus, of course, it makes it hard to talk about future releases.

Not that it makes a lot of sense to talk about future releases other
than the next two or so, but we could right now agree to use the
following replacement table.  Does your roadmap cover longer than
that?  Did I get the release year approximations wrong?

2.6.28 doesn't change
2.6.29 <-> 2009.1
2.6.30 <-> 2009.2
2.6.31 <-> 2009.3
2.6.32 <-> 2010.1
2.6.33 <-> 2010.2
2.6.34 <-> 2010.3
2.6.35 <-> 2010.4

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
--
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/