public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <t.artem@lycos.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: On the kernel numbering scheme
Date: Mon, 16 Apr 2018 16:04:35 +0500	[thread overview]
Message-ID: <e7b554d738de83268f4fc06dd6f12ada@lycos.com> (raw)

Hello all,

I know this proposal has already been made great many times but I'd like 
to repeat it and have a healthy discussion about it.

The current kernel numbering scheme makes no sense at all because the 
first two numbers don't represent anything at all. They had some meaning 
back in the 1.x 2.x 3.x days but then with the introduction of the new 
rolling development model, they became worthless.

I'd love to change the kernel numbering scheme to this:

YYYY.RELEASE.PATCH_LEVEL

So that the first kernel to be released in 2019 will be numbered 
2019.0(.0), and its consequent releases will be 2019.1, 2019.2, 2019.3, 
etc. and its stable patches will be 2019.0.1, 2019.0.2, 2019.0.3, 
2019.0.4, etc.

With this scheme you can easily see how fresh your kernel is and there's 
no need arbitrary raise the first number because it always matches the 
current year.

There's one minor detail which might raise some questions: there are 
release candidates and then there's a release, so for the development 
which starts before the year end we might start with e.g. 2018.5-rc1 and 
then if the actual release crosses a new year mark we simply turn 
2018.5-rc7 into 2019.0.0.

Best regards,
Artem S. Tashkinov

             reply	other threads:[~2018-04-16 11:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 11:04 Artem S. Tashkinov [this message]
2018-04-17  0:55 ` On the kernel numbering scheme \0xDynamite
2018-04-17 16:27   ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7b554d738de83268f4fc06dd6f12ada@lycos.com \
    --to=t.artem@lycos.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox