Linux 4.9 Will Be the Next LTS Kernel Branch, Says Greg Kroah-Hartman (softpedia.com)

Reader prisoninmate writes: Renowned Linux kernel developer and maintainer Greg Kroah-Hartman said on Friday that the next LTS (Long-Term Support) kernel branch will be Linux 4.9. The development cycle of a new Linux kernel branch doesn't take more than a month and a half or a maximum of two months, depending if the respective series will receive seven or eight Release Candidate (RC) milestones, but LTS releases are picked by veteran kernel developers from time to time when older ones reach end of life (EOL). If Linux kernel 4.8 will be a normal release with a total of seven RCs and it'll be announced on day of September 25, then the development cycle of the Linux 4.9 kernel should start with the first Release Candidate development snapshot on October 9, 2016. But if Linux kernel 4.8 will have eight RCs, then we should see Linux kernel 4.9 LTS RC1 one week later, on October 16.

Comments

Re:So how long will the support be?

[freakingme]

It will be for a long term. You're welcome.

No plan whatsoever

[Anonymous Coward]

It seems like the kernel people have no plan whatsoever. Kernels are EOL'd when they feel like it and the next LTS version is picked arbitrarily (there is nothing especially stable about 4.9, in case you are wondering).

Version numbers are mostly meaningless: Major versions change when Linus feels like it. Major breakage (as in, systems no longer booting) and major API changes happen even in minor versions. Version A.b isn't just an incremental update to A.a. It might bring an entirely new, experimental network stack, for example.

Then there's the ABI instability. FreeBSD, for example, guarantees ABI stability between major versions. In Windows, a driver written for Windows 7 has a good chance of working in Windows 10. In Linux, you can't even get a compiled module to insert cleanly between two compiles of the same kernel with slightly different options.

All of this makes it painful to develop for Linux, especially writing drivers. You either beg the kernel people to accept your driver in the tree (and hope that they maintain it), or you ship your driver in source form to users and fervently hope that your users manage to compile it (they won't).

And before you say "But Nvidia...", not all of us have the resources to build a nice, clean driver install package. And this assumes that you can even reliably get the source/headers for your kernel in the first place, which, for example, in the case of the Raspberry Pi, isn't exactly easy.

Re:No plan whatsoever

[Anonymous Coward]

If you can't get the code you wrote accepted by the kernel developers, then I don't want it running on my system.

Re:No plan whatsoever

[kroah]

Version numbers do mean nothing, we have always said that as kernel developers.

We don't break external APIs that people use, we break internal ones all the time, for good reasons. Read stable_api_nonsense.txt in the Linux kernel source tree for why we do this.

And I will take _any_ kernel driver into the tree, just send it to me, we don't reject anything, much to many people annoyance...

greg k-h

TFS is wrong

[Kjella]

The development cycle of a new Linux kernel branch doesn't take more than a month and a half or a maximum of two months, depending if the respective series will receive seven or eight Release Candidate (RC) milestones.

No. One month merge window, ~2 months with weekly RCs. If the kernel releases early the merge window widens so they're on a very stable three month cycle. You'd think an post about the kernel would do a minimum of fact-checking, but no...

Re:PC Police!! Pull over!!

[Masked Coward]

I'm just not sure which is his wife's boyfriend's last name.... Kroah, or Hartman?