Sender | Message | Time |
---|---|---|
27 Mar 2025 | ||
This is a very good question. I think we should, but only if support will end during the support period of 25.05 | 02:59:58 | |
Support on non-LTS ends as soon as a new non-LTS is released, so that pretty much means they all get dropped during the support period of 25.05. | 03:01:45 | |
So 24 is the newest non-LTS and it will go out of support in September | 03:02:47 | |
https://www.oracle.com/java/technologies/java-se-support-roadmap.html | 03:03:14 | |
(And there's a long lecture about there being no such thing as LTS OpenJDK, it depends upon each vendor, etc. But for practical purposes I'm pretty sure there is no Open Source OpenJDK release that supports non-LTS releases longer than Oracle) | 03:05:36 | |
So by this logic it should be: 25.05: 8, 11, 17, 21 25.11: 8, 11, 17, 21, 25 (unless people agree that 8 can be dropped) | 03:14:20 | |
For reference here's output from my SDKMAN! on macOS:
| 03:15:00 | |
They don't support 8. You can see that 22.02 is "local only" which means it has disappeared from their servers. And the 23 and 24 releases are currently available/active. | 03:16:50 | |
This is roughly the behavior I would like to see on unstable | 03:17:24 | |
24.11 has jdk23 even though it is now unsupported | 03:19:50 | |
it's sorta Oracle's own poor decision that they offer no overlap in support period | 03:22:22 | |
even we manage a month | 03:22:27 | |
I get the impression they essentially see non-LTS releases as previews rather than something production oriented | 03:22:54 | |
Here is Temurin's policy: https://adoptium.net/en-GB/support/ | 03:24:00 | |
I think most of the downstream builds have the same policy because it's essentially a matter of what commits Oracle will do | 03:25:22 | |
They use the word "Availability". There is a difference between "availability" and support. | 03:25:31 | |
For Nix, I would define availability as existing on master , but one could argue it is still available from an earlier hash. | 03:26:25 | |
I don't think there really is. "End of Service/Support Life - this code stream is no longer being maintained. No further builds of Eclipse Temurin are planned." | 03:26:29 | |
* For Nix, I would define availability as existing on master or unstable , but one could argue it is still available from an earlier hash. | 03:26:44 | |
ultimately, as soon as the next non-LTS is out, the next security advisory doesn't include patches for the previous one | 03:27:08 | |
Well, the question is whether the unsupported builds are available for download. | 03:27:13 | |
that's the reality that Oracle decides and everyone else is constrained by | 03:27:21 | |
I'm happy to use an unsupported build for a month or two. | 03:27:32 | |
would you be, if a critical severity CVE comes out days after it leaves support? | 03:28:10 | |
Well, yeah actually maintaining the JDK is a lot of work. But other vendors can do it and I think some of the big ones do for paid support. | 03:28:24 | |
because you can look at the stream of advisories and see that it's really like clockwork. it just comes down to gambling in the end | 03:28:43 | |
we don't like to gamble with users' security | 03:29:02 | |
I'd move really fast to the new one. But having releases deleted automatically, in the same PR as the new release seem excessive. | 03:29:14 | |
Well, I'm talking about availability on unstable. And saying that marking them as knownVulnerabilities immediately even if there aren't any. | 03:30:24 | |
I'd say users of NixOS who are not paying anything and using non-LTS releases on the unstable branch that are out of upstream support are gambling with their own security. And personally, I'm willing to do that because my main use case is developing alpha software that will eventually run on the stable branch. | 03:31:59 |