| 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
| ||
|
Message-ID: <AANLkTimqNW7zArcjtOkBvrn-dk=YE0_RG+u3yoMDTjwV@mail.gmail.com> Date: Thu, 21 Oct 2010 19:06:23 -0500 From: kevin granade <kevin.granade@...il.com> To: "Artem S. Tashkinov" <t.artem@...os.com> Cc: linux-kernel@...r.kernel.org Subject: Re: On Linux numbering scheme On Thu, Oct 21, 2010 at 3:02 PM, Artem S. Tashkinov <t.artem@...os.com> wrote: > Hello, > > > > As time passes by, the Linux numbering scheme makes even less sense. Some time ago there was a discussion on LKML about a new numbering scheme but it didn't come to any positive conclusion and then the subject was forgotten entirely. Not meaning to raise a clamour here (and I suppose I represent a large group of Linux users here). I'm willing to suggest a numbering scheme which I hope will answer all known complaints and criticism. What are the criticisms? I think outlining the goals might be a good idea: 1. Numbering scheme must monotonically increase with each release when evaluated as a version number, including transitioning from the current numbering system. 2. Individual elements of the version number should remain relatively small. > > > > The scheme is simple. We start either from 3.0.1 [.stable] or from 3.10.0 [.stable]. > > > > The first digit will remain "3" forever, to preserve compatibility with all existing utilities and internal Linux kernel code. So, the concern about older utilities breakage is answered here: both 3.0.1 and 3.10.1 are bigger than any currently released kernel. > > > > The second number will be either 10 (the current year) or 0 meaning we have reset the numbering altogether. However in my opinion 10 sounds better than 0. > > > > Now, more about the second and third numbers. The second number is just the current year in the 21 century or the same number minus 10. The third number will be incremented with every new release until the next year hits. So, the real next year we'll have 3.11.1, 3.11.2, 3.11.3, etc. Any particular reason not to continue the date-oriented format and have the third number be the numerical representation of the month rather than an incrementing numbering of the releases? It would still be monotonically increasing, which is the only requirement, right? > > > > Now comes a problem, what if we release kernel 3.10.1 this year and the development of the next one commences also this year? What will be the next release number? I suggest to assign the next release number as the following: > > > > 1) Either regardless the actual year the next kernel gets released (this way the kernel development started in 2010 will yield kernel 3.10.2 even though we hit the next year) or > > 2) By the day the kernel gets released, so while in development the kernel version remained 3.10.1-rcX, on the 15th of January, we rename it to 3.11.1. I very much think the first option is superior, the version number would mark the opening of the merge window. With the other option it introduces a discontinuity into the process that seems unnecessary. > > > Artem > -- > 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/ > -- 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