| 27 Mar 2025 |
 Tomodachi94 (they/them) | If we made Gradle 9 the default Gradle, that is definitely breaking. If we just added a gradle_9 attribute without making it default it on stable, we wouldn't be breaking stability guarantees | 00:36:36 |
| Tomodachi94 (they/them) | (Making it default in this case would mean assigning it to the regular gradle attribute) | 00:37:04 |
 emily | yes, backports of new packages are allowed | 00:38:19 |
| emily | changing default versions backwards-incompatibly isn't | 00:38:29 |
| emily | (so whatever Gradle 25.05 releases with will be the default for its lifespan) | 00:38:37 |
| emily | ah, which is exactly what tomodachi said :) | 00:38:50 |
 msgilligan | (My current Java on Nix work is using non-LTS JDKs 22->23->24->25 and I plan to stay on unstable until JDK 25 is in a stable release -- hopefully in November. I've been asking to keep the two most recent non-LTS JDKs in unstable, but don't have an opinion on what should be in stable branches. Though I'd probably lean to "package-drop-giddy" so people can focus on the newer stuff 😁) | 00:40:53 |
| msgilligan | And I'm trying to help out a little here and there, with things like jextract. | 00:41:57 |
| emily | we don't really have the resources to backport security fixes to EOL JDKs (not sure if anyone does other than Red Hat or something) | 00:42:18 |
| emily | theoretically we could keep them with knownVulnerabilities though | 00:42:24 |
| Tomodachi94 (they/them) | The reason I had this concern is because of what happened with Gradle 6 during the 24.11 release cycle. We ended up adding knownVulnerabilities to it, backporting that change to 24.05, then dropping it from unstable | 00:43:16 |
| Tomodachi94 (they/them) | "All roads lead to knownVulnerabilities" | 00:43:27 |
| msgilligan | This would work for me. I've had problems with JDKs being dropped when I have complex builds that require multiple recent versions. I'm trying to migrate off the dropped one as quickly as possible, but having say 23 disappear in the same commit as 24 appears makes this difficult. | 00:44:53 |
| emily | fwiw, nothing stops you from using OpenJDK 23 from the Nixpkgs revision before 24 was added | 00:46:06 |
| emily | while keeping the rest of your system on a newer rev | 00:46:15 |
| msgilligan | I just have to have two inputs in my flake? | 00:46:32 |
| emily | right | 00:46:35 |
| emily | being able to mix and match like that is part of why we generally err on the side of dropping stuff to ease maintainer burden | 00:46:55 |
| msgilligan | But I can't do that if I want to submit to Nixpkgs itself, right? | 00:47:19 |
| emily | it won't get updates to its dependencies, but the complex JIT engine is already the riskiest dependency in the tree anyway :) | 00:47:19 |
| Tomodachi94 (they/them) | Correct | 00:47:44 |
| msgilligan | This is why jextract had to be marked as broken, for example. | 00:48:28 |
| msgilligan | And a jextract-21 is practically useless because the features it relies on were "preview" and not final. Then when I updated to the latest jextract it generates code that requires JDK 23, so that forces anything that uses its output to JDK 23. | 00:50:01 |
| msgilligan | I would say jextract and jextract-21 should both be removed from 25.05 stable. And as soon as we get jextract 23, I would say we should remove jextract-21 from unstable. | 00:51:32 |
| emily | have they not even updated to 23 yet? 🫠 | 00:52:59 |
| emily | it's a little bizarre that the OpenJDK project can't keep up with their own release cycle :) | 00:53:16 |
| emily | I guess this is why people stick to LTSes | 00:53:27 |
| Tomodachi94 (they/them) | Off-topic: Lovely, Nixpkgs has a working Codespaces default now >:) | 00:54:10 |
| msgilligan | They have, and I've made a PR that works on aarch64-darwin but not aarch64-linux (thought that may be true of the upstream too) | 00:54:15 |
| Tomodachi94 (they/them) | (In theory; it's still setting itself up) | 00:54:30 |
