|
@@ -18,17 +18,17 @@ major kernel release happening every two or three months. The recent
|
|
|
release history looks like this:
|
|
|
|
|
|
====== =================
|
|
|
- 2.6.38 March 14, 2011
|
|
|
- 2.6.37 January 4, 2011
|
|
|
- 2.6.36 October 20, 2010
|
|
|
- 2.6.35 August 1, 2010
|
|
|
- 2.6.34 May 15, 2010
|
|
|
- 2.6.33 February 24, 2010
|
|
|
+ 4.11 April 30, 2017
|
|
|
+ 4.12 July 2, 2017
|
|
|
+ 4.13 September 3, 2017
|
|
|
+ 4.14 November 12, 2017
|
|
|
+ 4.15 January 28, 2018
|
|
|
+ 4.16 April 1, 2018
|
|
|
====== =================
|
|
|
|
|
|
-Every 2.6.x release is a major kernel release with new features, internal
|
|
|
-API changes, and more. A typical 2.6 release can contain nearly 10,000
|
|
|
-changesets with changes to several hundred thousand lines of code. 2.6 is
|
|
|
+Every 4.x release is a major kernel release with new features, internal
|
|
|
+API changes, and more. A typical 4.x release contain about 13,000
|
|
|
+changesets with changes to several hundred thousand lines of code. 4.x is
|
|
|
thus the leading edge of Linux kernel development; the kernel uses a
|
|
|
rolling development model which is continually integrating major changes.
|
|
|
|
|
@@ -70,20 +70,19 @@ will get up to somewhere between -rc6 and -rc9 before the kernel is
|
|
|
considered to be sufficiently stable and the final 2.6.x release is made.
|
|
|
At that point the whole process starts over again.
|
|
|
|
|
|
-As an example, here is how the 2.6.38 development cycle went (all dates in
|
|
|
-2011):
|
|
|
+As an example, here is how the 4.16 development cycle went (all dates in
|
|
|
+2018):
|
|
|
|
|
|
============== ===============================
|
|
|
- January 4 2.6.37 stable release
|
|
|
- January 18 2.6.38-rc1, merge window closes
|
|
|
- January 21 2.6.38-rc2
|
|
|
- February 1 2.6.38-rc3
|
|
|
- February 7 2.6.38-rc4
|
|
|
- February 15 2.6.38-rc5
|
|
|
- February 21 2.6.38-rc6
|
|
|
- March 1 2.6.38-rc7
|
|
|
- March 7 2.6.38-rc8
|
|
|
- March 14 2.6.38 stable release
|
|
|
+ January 28 4.15 stable release
|
|
|
+ February 11 4.16-rc1, merge window closes
|
|
|
+ February 18 4.16-rc2
|
|
|
+ February 25 4.16-rc3
|
|
|
+ March 4 4.16-rc4
|
|
|
+ March 11 4.16-rc5
|
|
|
+ March 18 4.16-rc6
|
|
|
+ March 25 4.16-rc7
|
|
|
+ April 1 4.17 stable release
|
|
|
============== ===============================
|
|
|
|
|
|
How do the developers decide when to close the development cycle and create
|
|
@@ -99,37 +98,42 @@ 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 2.6.x
|
|
|
+larger, creating even more regressions the next time around. So most 4.x
|
|
|
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 consisting of Greg Kroah-Hartman. The stable team
|
|
|
-will release occasional updates to the stable release using the 2.6.x.y
|
|
|
+will release occasional updates to the stable release using the 4.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 than one development cycle past their initial release. So,
|
|
|
-for example, the 2.6.36 kernel's history looked like:
|
|
|
+for example, the 4.13 kernel's history looked like:
|
|
|
|
|
|
============== ===============================
|
|
|
- October 10 2.6.36 stable release
|
|
|
- November 22 2.6.36.1
|
|
|
- December 9 2.6.36.2
|
|
|
- January 7 2.6.36.3
|
|
|
- February 17 2.6.36.4
|
|
|
+ September 3 4.13 stable release
|
|
|
+ September 13 4.13.1
|
|
|
+ September 20 4.13.2
|
|
|
+ September 27 4.13.3
|
|
|
+ October 5 4.13.4
|
|
|
+ October 12 4.13.5
|
|
|
+ ... ...
|
|
|
+ November 24 4.13.16
|
|
|
============== ===============================
|
|
|
|
|
|
-2.6.36.4 was the final stable update for the 2.6.36 release.
|
|
|
+4.13.16 was the final stable update of the 4.13 release.
|
|
|
|
|
|
Some kernels are designated "long term" kernels; they will receive support
|
|
|
for a longer period. As of this writing, the current long term kernels
|
|
|
and their maintainers are:
|
|
|
|
|
|
- ====== ====================== ===========================
|
|
|
- 2.6.27 Willy Tarreau (Deep-frozen stable kernel)
|
|
|
- 2.6.32 Greg Kroah-Hartman
|
|
|
- 2.6.35 Andi Kleen (Embedded flag kernel)
|
|
|
+ ====== ====================== ==============================
|
|
|
+ 3.16 Ben Hutchings (very long-term stable kernel)
|
|
|
+ 4.1 Sasha Levin
|
|
|
+ 4.4 Greg Kroah-Hartman (very long-term stable kernel)
|
|
|
+ 4.9 Greg Kroah-Hartman
|
|
|
+ 4.14 Greg Kroah-Hartman
|
|
|
====== ====================== ===========================
|
|
|
|
|
|
The selection of a kernel for long-term support is purely a matter of a
|