tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Documentation: process: Arbitrarily bump kernel major version number

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>
[jc: tweaked the initial 9.x mention slightly]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20250922074219.26241-1-bagasdotme@gmail.com>

authored by

Bagas Sanjaya and committed by
Jonathan Corbet 44abc8fc 3a2ddc5f

+18 -23
+18 -23
Documentation/process/2.Process.rst
··· 13 13 The big picture 14 14 --------------- 15 15 16 - The kernel developers use a loosely time-based release process, with a new 17 - major kernel release happening every two or three months. The recent 18 - release history looks like this: 16 + The Linux kernel uses a loosely time-based, rolling release development 17 + model. A new major kernel release (which we will call, as an example, 9.x) 18 + [1]_ happens every two or three months, which comes with new features, 19 + internal API changes, and more. A typical release can contain about 13,000 20 + changesets with changes to several hundred thousand lines of code. Recent 21 + releases, along with their dates, can be found at `Wikipedia 22 + <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_. 19 23 20 - ====== ================= 21 - 5.0 March 3, 2019 22 - 5.1 May 5, 2019 23 - 5.2 July 7, 2019 24 - 5.3 September 15, 2019 25 - 5.4 November 24, 2019 26 - 5.5 January 6, 2020 27 - ====== ================= 28 - 29 - Every 5.x release is a major kernel release with new features, internal 30 - API changes, and more. A typical release can contain about 13,000 31 - changesets with changes to several hundred thousand lines of code. 5.x is 32 - the leading edge of Linux kernel development; the kernel uses a 33 - rolling development model which is continually integrating major changes. 24 + .. [1] Strictly speaking, the Linux kernel does not use semantic versioning 25 + number scheme, but rather the 9.x pair identifies major release 26 + version as a whole number. For each release, x is incremented, 27 + but 9 is incremented only if x is deemed large enough (e.g. 28 + Linux 5.0 is released following Linux 4.20). 34 29 35 30 A relatively straightforward discipline is followed with regard to the 36 31 merging of patches for each release. At the beginning of each development ··· 43 48 44 49 The merge window lasts for approximately two weeks. At the end of this 45 50 time, Linus Torvalds will declare that the window is closed and release the 46 - first of the "rc" kernels. For the kernel which is destined to be 5.6, 51 + first of the "rc" kernels. For the kernel which is destined to be 9.x, 47 52 for example, the release which happens at the end of the merge window will 48 - be called 5.6-rc1. The -rc1 release is the signal that the time to 53 + be called 9.x-rc1. The -rc1 release is the signal that the time to 49 54 merge new features has passed, and that the time to stabilize the next 50 55 kernel has begun. 51 56 ··· 94 99 achieve; there are just too many variables in a project of this size. 95 100 There comes a point where delaying the final release just makes the problem 96 101 worse; the pile of changes waiting for the next merge window will grow 97 - larger, creating even more regressions the next time around. So most 5.x 98 - kernels go out with a handful of known regressions though, hopefully, none 99 - of them are serious. 102 + larger, creating even more regressions the next time around. So most kernels 103 + go out with a handful of known regressions, though, hopefully, none of them 104 + are serious. 100 105 101 106 Once a stable release is made, its ongoing maintenance is passed off to the 102 107 "stable team," currently Greg Kroah-Hartman. The stable team will release 103 - occasional updates to the stable release using the 5.x.y numbering scheme. 108 + occasional updates to the stable release using the 9.x.y numbering scheme. 104 109 To be considered for an update release, a patch must (1) fix a significant 105 110 bug, and (2) already be merged into the mainline for the next development 106 111 kernel. Kernels will typically receive stable updates for a little more