Greg now officially deemed #Linux 6.12 as a longterm #kernel by adding it to https://www.kernel.org/category/releases.html right after marking 4.19 as EOL; ohh, and he marked the #LinuxKernel 6.11 series as EOL today, too!

For details see the latest commits here: https://git.kernel.org/pub/scm/docs/kernel/website.git/log/

2/ Regarding the #Linux 4.19.y EOL, see also this nice and interesting farewell note from @gregkh:

https://lore.kernel.org/all/2024120520-mashing-facing-6776@gregkh/

'"[#LinuxKernel 4.19] had a good life, despite being born out of internal strife. […]

As a "fun" proof that this one is finished […] , I looked at the "unfixed" CVEs from this #kernel release. Currently it is a list 983 CVEs long, too long to list here. […]"'

@kernellogger @gregkh You shocked me a bit with "farewell note from @gregkh", really sounded like Greg was retiring...

@AndresFreundTec @gregkh hehe, sorry, that was not my intention; added a "series" to the toot to avoid that.

3/ And in case you are wondering why nearly thousand issues that received a CVE were not fixed in the #Linux 4.19.y series, see this blog post @gregkh published in 2018.

http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

In particular the sections in the area screenshotted below.

The TLDR basically is: on a typical generic server, you don't want to use #kernel from older longterm series; instead use the latest release from the newest #LinuxKernel stable or longterm (aka LTS) series.

@kernellogger Why are nearly all LTS kernels projected to have an EOL in December 2026? Shouldn't a newer LTS kernel have an EOL further in the future than a very old one?

@bitpirate long story short:

most longterm kernels used to be supported for two years; then for a while the number went up to six for a while; now it's being slowly scaled down to two again, which results in the effect you mentioned.

That being said: the projected EOL dates might still change to a later date if people step up to help maintaining these series.