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@xxxxxxxxxxxxxxxxxxx>
M: Sasha Levin <sashal@xxxxxxxxxx>
This can go on separate patch, I think.
Thanks.
--
An old man doll... just what I always wanted! - Clara
