Re: On Linux numbering scheme

[kevin granade]

On Thu, Oct 21, 2010 at 3:02 PM, Artem S. Tashkinov <t.artem@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/