Re: [PATCH] Documentation: process: Do not hardcode kernel major version number

[Bagas Sanjaya <bagasdotme@gmail.com>]

On 9/14/25 04:40, Randy Dunlap wrote:
> On 9/12/25 6:51 PM, Bagas Sanjaya wrote:   
>> -The kernel developers use a loosely time-based release process, with a new
>> -major kernel release happening every two or three months.  The recent
>> -release history looks like this:
>> +Linux kernel uses a loosely time-based, rolling release development model.
> 
>     The Linux kernel
> 
>> +A new major kernel release (a.x) [1]_ happens every two or three monts, which
> 
> I'm much more used to x.y                                           months,
> 

The reason I use a.x is because a is indeed supermajor (only incremented 
on occasional cases i.e. in Linux kernel when x gets large enough), and
x is already used as second placeholder component.

>> +comes with new features, internal API changes, and more. A typical release
>> +can contain about 13,000 changesets with changes to several hundred thousand
>> +lines of code. Recent releases, along with their dates, can be found at
>> +`Wikipedia <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
>>   
>> -	======  =================
>> -	5.0	March 3, 2019
>> -	5.1	May 5, 2019
>> -	5.2	July 7, 2019
>> -	5.3	September 15, 2019
>> -	5.4	November 24, 2019
>> -	5.5	January 6, 2020
>> -	======  =================
>> -
>> -Every 5.x release is a major kernel release with new features, internal
>> -API changes, and more.  A typical release can contain about 13,000
>> -changesets with changes to several hundred thousand lines of code.  5.x is
>> -the leading edge of Linux kernel development; the kernel uses a
>> -rolling development model which is continually integrating major changes.
>> +.. [1] Strictly speaking, Linux kernel do not use semantic versioning
> 
>                               the Linux kernel does not
> 
>> +       number scheme, but rather a.x pair identifies major release
> 
> x.y ?
> m.n ?
>                               rather the a.x
> 

See my above reply.

>> +       version as a whole number. For each release, x is incremented,
>> +       but a is incremented only if x is deemed large enough (e.g.
>> +       Linux 5.0 is released following Linux 4.20).
>>   
>>   A relatively straightforward discipline is followed with regard to the
>>   merging of patches for each release.  At the beginning of each development
>> @@ -48,9 +42,9 @@ detail later on).
>>   
>>   The merge window lasts for approximately two weeks.  At the end of this
>>   time, Linus Torvalds will declare that the window is closed and release the
>> -first of the "rc" kernels.  For the kernel which is destined to be 5.6,
>> +first of the "rc" kernels.  For the kernel which is destined to be a.x,
>>   for example, the release which happens at the end of the merge window will
>> -be called 5.6-rc1.  The -rc1 release is the signal that the time to
>> +be called a.x-rc1.  The -rc1 release is the signal that the time to
>>   merge new features has passed, and that the time to stabilize the next
>>   kernel has begun.
>>   
>> @@ -99,13 +93,13 @@ release is made.  In the real world, this kind of perfection is hard to
>>   achieve; there are just too many variables in a project of this size.
>>   There comes a point where delaying the final release just makes the problem
>>   worse; the pile of changes waiting for the next merge window will grow
>> -larger, creating even more regressions the next time around.  So most 5.x
>> -kernels go out with a handful of known regressions though, hopefully, none
>> -of them are serious.
>> +larger, creating even more regressions the next time around.  So most kernels
>> +go out with a handful of known regressions though, hopefully, none of them
> 
> I would add another comma:        regressions,
> 
>> +are serious.
>>   
>>   Once a stable release is made, its ongoing maintenance is passed off to the
>>   "stable team," currently Greg Kroah-Hartman. The stable team will release
> 
> and Sasha Levin:
> STABLE BRANCH
> M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> M:	Sasha Levin <sashal@kernel.org>
> 

This can go on separate patch, I think.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara