Standardize on specific JDK Versions

[jlesquembre]

Part of #313216

Issue description

We currently have several JDK derivations, such as jdk22, jdk20, and a single generic package jdk. However, jdk points to version 21, while a dedicated jdk21 package is missing. This inconsistency can be confusing.

Proposal:

• Introduce dedicated packages: Add a jdk21 top-level package alongside the existing jdk alias, which would continue to point to the latest LTS version.

  • Done in openjdk21, openjfx21: init at 21 #258507

• Enforce specific version references: Disallow references to jdk within other derivations. Instead, require explicit references to specific versions like jdk17 or jdk21. This approach prevents package breakage when the jdk alias is updated to a newer LTS version.

• Prioritize LTS versions: When possible, encourage referencing LTS versions. For example, if a program works with both jdk17 and jdk18, prefer jdk17 due to its LTS status.

[raboof]

• Add a jdk21 top-level package alongside the existing jdk alias, which would continue to point to the latest LTS version.

(seems this was already done in #258507)

• Disallow references to jdk within other derivations. Instead, require explicit references to specific versions like jdk17 or jdk21. This approach prevents package breakage when the jdk alias is updated to a newer LTS version.

The disadvantage of this is that, once we update jdk beyond jdk21, for packages that have jdk21 as an input we can't distinguish between 'this package is on jdk21 because it doesn't work with the default jdk' and 'this package is on jdk21 because nobody bothered to update it'.

TBH, I think we should encourage referring to jdk, and if updating jdk breaks packages that's those packages maintainers' responsibility. If they're broken and somebody notices, we've found a new maintainer. If they're broken and nobody notices, perhaps we should drop those packages anyway.

Prioritize LTS versions: When possible, encourage referencing LTS versions. For example, if a program works with both jdk17 and jdk18, prefer jdk17 due to its LTS status.

Why? I think I'd prefer having a little breakage each non-LTS upgrade over having a lot of breakage each LTS upgrade.

[jerith666]

I tend to agree with @raboof that it's better to have individual packages use the latest JDK unless there's a specific reason not to. (It's what I did back in e7cfa26.)

The disadvantage of this is that, once we update jdk beyond jdk21, for packages that have jdk21 as an input we can't distinguish between 'this package is on jdk21 because it doesn't work with the default jdk' and 'this package is on jdk21 because nobody bothered to update it'.

This could be addressed by creating jdk_latest and jdk_latest_lts aliases, and let packages that don't need a specific version use those, so that it's clear they want to remain on (either definition of) the latest.

[raboof]

This could be addressed by creating jdk_latest and jdk_latest_lts aliases, and let packages that don't need a specific version use those, so that it's clear they want to remain on (either definition of) the latest.

What would be the difference between jdk and jdk_latest?

[jerith666]

I figured we would get rid of jdk, forcing users of the JDK to be more explicit about what they want.

[jlesquembre]

The rationale here is that the maintainer of a package that depends on jdkXX should be responsible for updating the version manually. This approach avoids mass rebuilds and potential breakage of dependent packages when we want to update the jdk to a newer version.

On the topic of recommending an LTS version, this gives more time to maintainers to test the new JDK version. Additionally, if a package depends on an LTS version that becomes EOL, it's a strong indicator that the package isn't maintained anymore and probably should be removed.

My main goal is to be able to quickly update the JDK to the latest version without much burden. I want to avoid cases like #273811, where we had an EOL JDK for too long, probably because we were afraid of mass rebuilds and breaking dependent packages.

However, you also made a valid point. If we decide that the policy is to update the JDK, accepting that some breakage might occur, and fixing that falls on the responsibility of the dependent packages' maintainers (not the JDK maintainers), that's also acceptable.

Let me know your thoughts. In any case, once we agree on a policy, we should document it and start enforcing it.

[raboof]

This approach avoids mass rebuilds and potential breakage of dependent packages when we want to update the jdk to a newer version.

This is indeed an advantage of having packages depend on specific versions.

The disadvantage is that packages that depend on specific versions are likely to remain on older versions even when they'd work fine on the latest version, increasing the likelihood that multiple JVM versions are installed on any given system. This is because maintainers don't have a strong incentive to test the upgrade of their package to the latest JVM.

My main goal is to be able to quickly update the JDK to the latest version without much burden. I want to avoid cases like #273811, where we had an EOL JDK for too long, probably because we were afraid of mass rebuilds and breaking dependent packages.

Totally agree. I think this may have partly been due to the fact that so far it was unclear whose responsibility it was to test/fix affected packages.

In any case, once we agree on a policy, we should document it

Definitely! Perhaps a sweet spot is to document a preference for tracking the latest JDK, making it clear to maintainers that this does mean it's up to them to keep testing the package on upgrades, but still allow them to stick to specific versions if they're not up to that.

Perhaps we can also standardize on some (ofborg?) command to test a representative set of packages before updating?

[jerith666]

If we decide that the policy is to update the JDK, accepting that some breakage might occur, and fixing that falls on the responsibility of the dependent packages' maintainers (not the JDK maintainers), that's also acceptable.

document a preference for tracking the latest JDK, making it clear to maintainers that this does mean it's up to them to keep testing the package on upgrades, but still allow them to stick to specific versions if they're not up to that.

I support both of these policy ideas.