linux-kernel - Re: On Linux numbering scheme

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] [day] [month] [year] [list]

Message-ID: <AANLkTikyyDuMemndfezEijTHHW6798+yQO_FmLyjyPTV@mail.gmail.com>
Date:	Fri, 22 Oct 2010 11:51:31 -0500
From:	kevin granade <kevin.granade@...il.com>
To:	Genes MailLists <lists@...ience.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: On Linux numbering scheme

On Fri, Oct 22, 2010 at 8:25 AM, Genes MailLists <lists@...ience.com> wrote:
> On 10/22/2010 06:41 AM, Alexey Dobriyan wrote:
>> On Fri, Oct 22, 2010 at 1:33 PM, Artem S. Tashkinov <t.artem@...os.com> wrote:
>>> What can you say about kernel 2.6.32? Almost nothing.
>>>
>>> What can you say about kernel 3.11.3? - it is the third release of
>>> Linux in 2011.
>>
>> And? What a useless information.
>>
>> BTW, it should be 3.2011.3, see Y2K.
>> --
>
>   If you -really- wanna go that route - may as well be
>
>      20.11.3.18

I think the reason day was excluded by previous suggestions is that
the current development model doesn't generate a "blessed" version on
anything close to a daily rate.  Even if you wanted to incorporate the
-rcs or -next into this scheme, it seems like it'd be somewhat
problematic since the day field would drop in value during development
e.g.
20.11.3.18 = 2.6.37-rc1
20.11.3.25 = 2.6.37-rc2
20.11.4.2  = 2.6.36-rc3

That having been said, <century>.<year>.<month> would be as valid as
3.<year>.<month>, and might help drive home the point that the version
number is "a point in development" rather than some kind of "indicator
of feature releases".

>
>    century.decade.month.day .. that way we don't have problem until we
> hit the year 10,000 ... :-)

Or until the New Galactic Calendar is introduced... ;)

Silliness aside, what are the deficiencies of the current numbering
that are being addressed here?  The only things I can come up with
are, "major number is getting too big" and "development no longer
follows a major/minor feature based model, so the version numbering
scheme should reflect this".  Are there any other reasons for a
change?

Kevin

>
>
>  g
> --
> 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/