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),
arbitrarily bump it to 9, giving a headroom for a decade.

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

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
Changes since v1 [1]:

  * Arbitrarily bump major number rather than replacing it with placeholder
    (Jon)
  * Apply proofreading corrections (Randy)

[1]: https://lore.kernel.org/linux-doc/20250913015147.9544-1-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..bbd955d91df0cd 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:
+The Linux kernel uses a loosely time-based, rolling release development model.
+A new major kernel release (9.x) [1]_ happens every two or three months, 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, the Linux kernel does not use semantic versioning
+       number scheme, but rather the 9.x pair identifies major release
+       version as a whole number. For each release, x is incremented,
+       but 9 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 9.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 9.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 9.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: 348011753d99b146c190aae262ee361d03cb0c5e
-- 
An old man doll... just what I always wanted! - Clara

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),
> arbitrarily bump it to 9, giving a headroom for a decade.
>
> Note that the version number examples are kept to illustrate the
> numbering scheme.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>

Just FYI, I've pretty much shut docs down for the upcoming merge window.
I'm probably not the only one.

Thanks,

jon

On 9/22/25 19:53, Jonathan Corbet wrote:
> 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),
>> arbitrarily bump it to 9, giving a headroom for a decade.
>>
>> Note that the version number examples are kept to illustrate the
>> numbering scheme.
>>
>> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> 
> Just FYI, I've pretty much shut docs down for the upcoming merge window.
> I'm probably not the only one.
> 

So it is slated for 6.19 then?

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

Bagas Sanjaya <bagasdotme@gmail.com> writes:

> On 9/22/25 19:53, Jonathan Corbet wrote:
>> 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),
>>> arbitrarily bump it to 9, giving a headroom for a decade.
>>>
>>> Note that the version number examples are kept to illustrate the
>>> numbering scheme.
>>>
>>> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
>> 
>> Just FYI, I've pretty much shut docs down for the upcoming merge window.
>> I'm probably not the only one.
>> 
>
> So it is slated for 6.19 then?

If it's not in docs-next (or some other subsystem tree) now then yes, it
will wait another cycle.  We are at -rc7, after all.

jon

On 9/22/25 21:07, Jonathan Corbet wrote:
> Bagas Sanjaya <bagasdotme@gmail.com> writes:
> 
>> So it is slated for 6.19 then?
> 
> If it's not in docs-next (or some other subsystem tree) now then yes, it
> will wait another cycle.  We are at -rc7, after all.
> 

OK, thanks!

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