redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

docs: update kernel versions and dates in tables 

Every once in a while, we should update the examples
to reflect more recent kernel versions.

Update the tables describing kernel releases, the merge window,
and current longterm maintained kernel, from 2.6-era kernels
to 4.x.

Signed-off-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
hifive-unleashed-5.1
Tim Bird 2018-05-23 15:20:14 -07:00 committed by Jonathan Corbet
parent 45c9a74f64
commit 8962e40c19
1 changed files with 38 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

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