On 05/24/2018 12:20 AM, Tim Bird wrote: > 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@xxxxxxxx> > --- > Documentation/process/2.Process.rst | 72 +++++++++++++++++++------------------ > 1 file changed, 38 insertions(+), 34 deletions(-) > > diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst > index ce5561b..a9c46dd 100644 > --- a/Documentation/process/2.Process.rst > +++ b/Documentation/process/2.Process.rst > @@ -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 > ====== ====================== =========================== Is 4.14 not very long-term stable kernel ? > > The selection of a kernel for long-term support is purely a matter of a -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
