| 27 Mar 2025 |
 Tomodachi94 (they/them) | If we go this route, https://github.com/nixos/nixpkgs/issues/358845 would also need to be dealt with | 00:18:20 |
 msgilligan | * Gradle 8.14 is needed to be able to build for JDK 24, but still requires JDK 23 (or earlier) to run Gradle itself. | 00:30:52 |
| Tomodachi94 (they/them) | As for Java itself, I think we're okay on breaking changes? Java 23 is LTS afaict, and 24 was released about a week ago | 00:34:05 |
| Tomodachi94 (they/them) | As for Java itself, I think we're okay on breaking changes? OpenJDK 23 is LTS afaict, and 24 was released about a week ago | 00:34:12 |
| msgilligan | Do stable releases of Nix commonly add newly released versions of packages (such as Gradle 9)? Is that something that users expect? (Can 7 be dropped without an obligation to add 9 later?) | 00:34:27 |
| msgilligan | JDK 21 is LTS and the next one will be JDK 25 (in September) | 00:35:06 |
| Tomodachi94 (they/them) | If we made Gradle 9 the default Gradle, that is definitely breaking. If we just added a `gradle_9' attribute without changing it on stable, we wouldn't be breaking stability guarantees | 00:36:09 |
| Tomodachi94 (they/them) | If we made Gradle 9 the default Gradle, that is definitely breaking. If we just added a gradle_9 attribute without changing it on stable, we wouldn't be breaking stability guarantees | 00:36:24 |
| 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 |
