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

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

[Bagas Sanjaya]

The big picture section of 2.Process.rst currently hardcodes major
version number to 5 since fb0e0ffe7fc8e0 ("Documentation: bring process
docs up to date"). As it can get outdated when it is actually
incremented (the recent is 6 and will be 7 in the near future), replace
it with the placeholder.

Note that the version number examples are kept to illustrate the
numbering scheme.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/process/2.Process.rst | 40 ++++++++++++-----------------
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index ef3b116492df08..668d5559ded039 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -13,24 +13,18 @@ how the process works is required in order to be an effective part of it.
 The big picture
 ---------------
 
-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.
+A new major kernel release (a.x) [1]_ happens every two or three monts, which
+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
+       number scheme, but rather a.x pair identifies major release
+       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
+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
-occasional updates to the stable release using the 5.x.y numbering scheme.
+occasional updates to the stable release using the a.x.y numbering scheme.
 To be considered for an update release, a patch must (1) fix a significant
 bug, and (2) already be merged into the mainline for the next development
 kernel. Kernels will typically receive stable updates for a little more

base-commit: f44a29784f685804d9970cfb0d3439c9e30981d7
-- 
An old man doll... just what I always wanted! - Clara

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

[Randy Dunlap]

On 9/12/25 6:51 PM, Bagas Sanjaya wrote:
> The big picture section of 2.Process.rst currently hardcodes major
> version number to 5 since fb0e0ffe7fc8e0 ("Documentation: bring process
> docs up to date"). As it can get outdated when it is actually
> incremented (the recent is 6 and will be 7 in the near future), replace
> it with the placeholder.
> 
> Note that the version number examples are kept to illustrate the
> numbering scheme.
> 
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/2.Process.rst | 40 ++++++++++++-----------------
>  1 file changed, 17 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> index ef3b116492df08..668d5559ded039 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -13,24 +13,18 @@ how the process works is required in order to be an effective part of it.
>  The big picture
>  ---------------
>  
> -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,

> +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

> +       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>

> -occasional updates to the stable release using the 5.x.y numbering scheme.
> +occasional updates to the stable release using the a.x.y numbering scheme.
>  To be considered for an update release, a patch must (1) fix a significant
>  bug, and (2) already be merged into the mainline for the next development
>  kernel. Kernels will typically receive stable updates for a little more
> 
> base-commit: f44a29784f685804d9970cfb0d3439c9e30981d7

thanks.
-- 
~Randy

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

[Bagas Sanjaya]

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

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

[Randy Dunlap]

Hi,

On 9/13/25 8:18 PM, Bagas Sanjaya wrote:
> 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.

Do we use the word "supermajor" anywhere?
$ grep ...
Nope.

How about we call it MAJOR (like the top-level Makefile does; well, it calls it
both VERSION and MAJOR[1]), so use
	m.x

I would say "or v.x" but that could be confusing when someone references a
v6.17-rc5 kernel.


[1]: from Makefile:VERSION = 6
PATCHLEVEL = 17
SUBLEVEL = 0
and
	echo \#define LINUX_VERSION_MAJOR $(VERSION);                    \
	echo \#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL);            \
	echo \#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)

G'day.
-- 
~Randy

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

[Bagas Sanjaya]

On 9/14/25 13:10, Randy Dunlap wrote:
> Do we use the word "supermajor" anywhere?
> $ grep ...
> Nope.
> 
> How about we call it MAJOR (like the top-level Makefile does; well, it calls it
> both VERSION and MAJOR[1]), so use
> 	m.x
> 

That's more sense (and that is indeed the term I use in the patch subject).

Thanks.

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

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

[Jonathan Corbet]

Bagas Sanjaya <bagasdotme@gmail.com> writes:

> The big picture section of 2.Process.rst currently hardcodes major
> version number to 5 since fb0e0ffe7fc8e0 ("Documentation: bring process
> docs up to date"). As it can get outdated when it is actually
> incremented (the recent is 6 and will be 7 in the near future), replace
> it with the placeholder.
>
> Note that the version number examples are kept to illustrate the
> numbering scheme.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/2.Process.rst | 40 ++++++++++++-----------------
>  1 file changed, 17 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> index ef3b116492df08..668d5559ded039 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -13,24 +13,18 @@ how the process works is required in order to be an effective part of it.
>  The big picture
>  ---------------
>  
> -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.
> +A new major kernel release (a.x) [1]_ happens every two or three monts, which
> +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>`_.

I have to admit that I'm not at all convinced that this change brings
clarity to the document; using real numbers grounds the text in a way
that "a.x" does not.

If we really think it's embarrassing to still say "5.whatever" here,
perhaps we should just change it to "9.whatever" and be good for a long
time?

Thanks,

jon

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

[Bagas Sanjaya]

On 9/16/25 23:07, Jonathan Corbet wrote:
> I have to admit that I'm not at all convinced that this change brings
> clarity to the document; using real numbers grounds the text in a way
> that "a.x" does not.
> 
> If we really think it's embarrassing to still say "5.whatever" here,
> perhaps we should just change it to "9.whatever" and be good for a long
> time?
> 

I think that's a good alternative idea.

Thanks.

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