Documentation/process/2.Process.rst | 40 ++++++++++++----------------- 1 file changed, 17 insertions(+), 23 deletions(-)
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! - ClaraBagas 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
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
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
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
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
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
© 2016 - 2025 Red Hat, Inc.