mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: xDynamite <dreamingforward@gmail.com>,
	"Artem S. Tashkinov" <t.artem@lycos.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: On the kernel numbering scheme
Date: Tue, 17 Apr 2018 09:27:46 -0700	[thread overview]
Message-ID: <954f8e10-ae72-3175-1bac-ffac6cae10f7@schaufler-ca.com> (raw)
In-Reply-To: <CAMjeLr-A7z=A3E3yqnZ_PZhekZPxhCDP=Cb0aWhemmv3MNAoPA@mail.gmail.com>

On 4/16/2018 5:55 PM, \0xDynamite wrote:
>  > 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),
> If you're going to suggest changes, then you should do it like this:
> Change major numbers ONLY when you've introduced a new incompatibility
> with your API and increment minor numbers for everything else.  THEN,
> the first number WILL mean something.  If your software changes
> something outside the way users communicate with the kernel (major
> changes) and just changes something that COULD affect other software,
> then have multiple partitions in your release number, like 3.5.41.

Release numbering schemes are the ultimate opportunity
for bikeshedding. It doesn't frikking matter. Schemes that
are designed to convey anything more important than sequence
break down eventually. Schemes that convey nothing but
sequence can't be used to emphasize a major change. Let this
sleeping dog lie. You have better things to worry about.
 

      reply	other threads:[~2018-04-17 16:28 UTC|newest]

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

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=954f8e10-ae72-3175-1bac-ffac6cae10f7@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=dreamingforward@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=t.artem@lycos.com \
    /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

all inboxes | Powered by JetHome®