Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8962e40c authored by Tim Bird's avatar Tim Bird Committed by Jonathan Corbet
Browse files

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: default avatarTim Bird <tim.bird@sony.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 45c9a74f

Documentation/process/2.Process.rst

+38 −34
Original line number Diff line number Diff line
@@ -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