github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-09-23 22:14:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

Documentation: process: Arbitrarily bump kernel major version number

Browse Source 
The big picture section of 2.Process.rst currently hardcodes major
version number to 5 since fb0e0ffe7f ("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>
[jc: tweaked the initial 9.x mention slightly]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20250922074219.26241-1-bagasdotme@gmail.com>
This commit is contained in:
Bagas Sanjaya 2025-09-22 14:42:19 +07:00 committed by Jonathan Corbet
parent 3a2ddc5fb1
commit 44abc8fcbf
1 changed files with 18 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
Documentation/process/2.Process.rst
View File

@ -13,24 +13,19 @@ how the process works is required in order to be an effective part of it.
The big picture The big picture
--------------- ---------------
The kernel developers use a loosely time-based release process, with a new The Linux kernel uses a loosely time-based, rolling release development
major kernel release happening every two or three months. The recent model. A new major kernel release (which we will call, as an example, 9.x)
release history looks like this: [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>`_.
====== ================= .. [1] Strictly speaking, the Linux kernel does not use semantic versioning
5.0 March 3, 2019 number scheme, but rather the 9.x pair identifies major release
5.1 May 5, 2019 version as a whole number. For each release, x is incremented,
5.2 July 7, 2019 but 9 is incremented only if x is deemed large enough (e.g.
5.3 September 15, 2019 Linux 5.0 is released following Linux 4.20).
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.
A relatively straightforward discipline is followed with regard to the A relatively straightforward discipline is followed with regard to the
merging of patches for each release. At the beginning of each development merging of patches for each release. At the beginning of each development
@ -48,9 +43,9 @@ detail later on).
The merge window lasts for approximately two weeks. At the end of this 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 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 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 merge new features has passed, and that the time to stabilize the next
kernel has begun. kernel has begun.
@ -99,13 +94,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. 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 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 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
kernels go out with a handful of known regressions though, hopefully, none go out with a handful of known regressions, though, hopefully, none of them
of them are serious. are serious.
Once a stable release is made, its ongoing maintenance is passed off to the 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 "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 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 bug, and (2) already be merged into the mainline for the next development
kernel. Kernels will typically receive stable updates for a little more kernel. Kernels will typically receive stable updates for a little more