On Mon, Jun 09, 2025 at 08:37:05AM -0600, Jonathan Corbet wrote:
Dante Strock <dantestrock@xxxxxxxxxxx> writes:
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index ef3b116492df..70f8a6603454 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -18,17 +18,17 @@ major kernel release happening every two or three months. The recent
release history looks like this:
====== =================
- 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
+ 6.10 July 14, 2024
+ 6.11 September 15, 2024
+ 6.12 November 17, 2024
+ 6.13 January 20, 2025
+ 6.14 March 24, 2025
+ 6.15 May 25, 2025
====== =================
-Every 5.x release is a major kernel release with new features, internal
+Every 6.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
+changesets with changes to several hundred thousand lines of code. 6.x is
the leading edge of Linux kernel development; the kernel uses a
rolling development model which is continually integrating major changes.
I do not object to these change and could apply this, but it might be
nice at some point to rephrase this stuff so that we don't end up doing
these updates repeatedly. After all, we'll be at 7.x within a year...
What about not hard-coding first version number component like below?
---- >8 ----
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index ef3b116492df08..47bcc6248a1338 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -13,24 +13,12 @@ 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:
-
- ====== =================
- 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.
+The kernel developers use a loosely time-based, rolling release development
+process. A new major kernel release (a.x) 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 `Linux Kernel Newbies site <https://kernelnewbies.org/LinuxVersions>`_.
A relatively straightforward discipline is followed with regard to the
merging of patches for each release. At the beginning of each development
@@ -46,13 +34,12 @@ merge window do not come out of thin air; they have been collected, tested,
and staged ahead of time. How that process works will be described in
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,
-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
-merge new features has passed, and that the time to stabilize the next
-kernel has begun.
+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 a.x, the release
+which happens at the end of the merge window will be called a.x-rc1. That
+release is the signal that the time to merge new features has passed, and that
+the time to stabilize the next kernel has begun.
Over the next six to ten weeks, only patches which fix problems should be
submitted to the mainline. On occasion a more significant change will be
@@ -99,13 +86,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
+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
Thanks.
