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
> 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.
Marxos
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.