On Thu, 29 Sep 2022, Emmanuel Bourg wrote: > previous releases is kept. This scenario is likely to continue in the future > since the Debian and Java releases are now synchronized on the same 2 years > cycle.
We could always delay Debian’s… (SCNR) or petition upstream to change theirs. > Assuming OpenJDK 17 users also have OpenJDK 11 installed that's about That is probably not a safe assumption. I have run into issues with more than one JRE installed, so I only ever install one. (But I doubt it matters much, for the larger picture, anyway.) > This is a significant share of users and it shows the extra effort > involved in maintaining an additional JDK is worth it. I think we have to distinguish between using the JDK/JRE as B-D/Depends of Debian packages, and using the JDK to develop and/or the JRE to run “other” software. For the former, we’re never going to get all software switched over to work with the newer one in time, especially considering we’ve apparently not switched the default to 17 over a year past the bullseye release. For the latter, I agree-ish. For bullseye and 17, we have https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#openjdk-17 which boils down to “11 is supported, 17 is not but we provide it as best-effort”. I think this suffices for the “other software” case. > Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping > of some packages that can't build directly with the latest JDK (more > specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK > 11 in unstable after the transition to OpenJDK 17. Who’s going to maintain that? For OpenJDK 8 I took over because, for quite some time (but not for a while) we had customers for whom I built this for older and newer Debian and *buntu releases. I’m now basically doing it because I started it, not because I have use myself any more. Doko dropped it, incidentally because of a bug he, with toolchain maintainer hat on, reported himself, and Tiago isn’t in a position to maintain things any more either AIUI. I am not going to take over 11 as well. (But if someone else wants to, I’d gladly share knowledge and experience. Or see my last paragraph.) History has shown that the (E)LTS contributors can and will do this on their own anyway so having 11 in sid to stage security support is not strictly necessary. If maintained, it is beneficial because then we’ll have a consistent state across releases. If unmaintained, however, not having it is better. So I think we should keep 11 around *only* if someone (could be Doko, could be someone else) commits to maintaining it. If nobody does, Scala and Kotlin are SOL. (There’s always the option of approaching my employer to make them make me maintain 11 as well as 8, for a fee, of course. I can barely justify continuing 8 right now. I’d do it but I’m not in a position to be able to do it through Freexian or freelancing.) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption! ****************************************************
