Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Operating Systems Linux

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

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.
This discussion has been archived. No new comments can be posted.

Linux 4.9 Will Be the Next LTS Kernel Branch, Says Greg Kroah-Hartman

Comments Filter:
  • No plan whatsoever (Score:2, Interesting)

    by 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 netw

    • Re: (Score:2, Insightful)

      by 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.

      • by trparky ( 846769 )
        But what do you do about the proprietary drivers that are often used by companies such as nVidia, ATi, Broadcom, and the various SoCs that are used in Android devices? Hell, I have a five year old router that's running TomatoUSB and it's still running kernel version 2.6.22.19 and there's no way to update the kernel without breaking the proprietary Broadcom SoC drivers that are needed for this router to work. Patches for security issues have to be back-ported to the 2.6.22 kernel and hope to God that the cha
    • by gweihir ( 88907 )

      To anybody with a clue, that is not much of a problem. Kernel-upgrades for Linux (much unlike as those for a certain other OS) rarely cause significant problems.

    • by kroah ( 751 ) on Friday August 12, 2016 @05:07PM (#52693637) Homepage Journal

      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

      • by Anonymous Coward

        As I sit here with a custom Linux 4.7 build running in a nested Linux/KVM instance in the background, reading /. for a few minutes as a short break before doing some coding, it occurs to me that many people don't say "thank you" enough these days. So, thank you for all your hard work over the years. It is deeply appreciated. -PCP

  • TFS is wrong (Score:5, Informative)

    by Kjella ( 173770 ) on Friday August 12, 2016 @02:58PM (#52692887) Homepage

    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...

Honesty is for the most part less profitable than dishonesty. -- Plato

Working...