Better Java versioning

[rarkins]

What would you like Renovate to be able to do?

Don't propose updating Java to "unstable" releases, e.g. from v11 to v15

Did you already have any implementation ideas?

Classify major versions like 15 as unstable? Then if someone is on an unstable version (e.g. 14 or 15) then they'd need to configure ignoreUnstable: false. Ideally we'd have a way to update them within a major release stream if they are already on it. Maybe we could achieve this separately by having a package rule in config:base like:

{
  "matchCurrentVersion": ">11",
  "ignoreUnstable": false
}

[viceice]

We can use https://api.adoptium.net/v3/info/available_releases to know which versions are stable (lts) https://api.adoptium.net/q/swagger-ui/#/Release%20Info/getAvailableReleases

[dc2tom]

Hi @rarkins we are attempting to configure our self-hosted renovate bot (Gitlab.com, private group) to only offer specific Java versions to teams, and only LTS versions at that. We have been experimenting with the "allowedVersions" regex and have come up a packageRules block like the below:

{
"matchDatasources":["docker"],
"matchPackagePatterns": ["amazoncorretto"],
"versioning": "loose",
"allowedVersions": "/:(8|11|17)\.[0-9]+\.[0-9]+/"
}

However, the bot still seems to decide that 19x is the version to offer..

"currentValue":"11.0.16","replaceString":"REDACTED_DOCKER_HUB_PROXY/amazoncorretto:11.0.16","autoReplaceStringTemplate":"{{depName}}{{#if newValue}}:{{newValue}}{{/if}}{{#if newDigest}}@{{newDigest}}{{/if}}","datasource":"docker","depType":"stage","depIndex":0,"updates":[{"bucket":"major","newVersion":"19.0.0","newValue":"19.0.0","newMajor":19,"newMinor":0,"updateType":"major","branchName":"renovate/REDACTED_DOCKER_HUB_PROXY-amazoncorretto-19.x"}

Is it likely that what we are attempting is supported or will we require an enhancement such as the suggestion from @viceice ?

Thanks

[rarkins]

Is the leading colon : in the regex pattern intentional?

If they doesn't solve it then try creating a public reproduction for us to look at

[setchy]

incase this is helpful, sharing the package rule we are using to limit to LTS releases.

I'm sure there are improvements that could be made to these rules, but they function

 "docker": {
    "packageRules": [
      {
        "description": "JDK runtime version - limit to preferred or acceptable versions (v11 lts or v17 lts)",
        "matchPackageNames": [
          "openjdk",
          "amazoncorretto"
        ],
        "allowedVersions": "/^(11|17)(\\.[0-9]+){0,2}/"
      },
      {
        "description": "JDK runtime version - limit to preferred or acceptable versions (v11 lts or v17 lts)",
        "matchPackageNames": [
          "eclipse-temurin",
          "adoptopenjdk"
        ],
        "versioning": "regex:^(?<major>\\d+)(\\.(?<minor>\\d+))?(\\.(?<patch>\\d+))?(_(?<build>\\d+))?(-(?<compatibility>.*))?$",
        "allowedVersions": "/^(11|17)(\\.[0-9]+){0,2}/"
      }
}

[rarkins]

@setchy would you like to contribute them to our workarounds presets in this repo? I think they'd be useful to enable by default for config:base users

[dc2tom]

Thanks for the quick responses I will report back with how we get on

[setchy]

Sure thing @rarkins - will raise a PR later today

[setchy]

draft pr for the workaround configuration #18007 - left a few open questions on it

[JakeWharton]

Don't propose updating Java to "unstable" releases, e.g. from v11 to v15

Java 15 was stable when it was released, and it remains stable to this day. It was supported for six months, and then Java 16 released (also as stable) which ended Java 15's support for bug fixes.

All stable releases of Java are stable. There are unstable features in every version (even LTS ones, which we'll get to) but those require a command-line opt-in. Unstable releases of Java are things like the EA builds. Right now, Java 23 is stable. But you can get unstable EA build of 24 here (https://jdk.java.net/24/), which will be stable in March.

Renovate is great because if you're on Java 15 when Java 16 comes out you get updated to it, and so on.

Now, there are LTS versions and non-LTS versions, but those are very different. For one, LTS is a vendor-provided designation and not something intrinsic to OpenJDK itself. Any vendor can make any version of Java LTS if they want to. Usually the vendors all generally agree on the LTS versions and share the load of backports. Some vendors offer medium-term support for other old versions, like Azul.

Java also is a cross-compiling tool. Developers should always¹ be using the latest JDK to develop and then either deploying on the latest JVM or an LTS JVM. This ensures they have access to the latest build features while still only using the language and library capabilities of their target JVM.

If you want to make an axis of the Java version data source for the wildely-agreed-upon LTS versions I think that's a great idea. However, I am opposed to it being the default and even more opposed to it being called "unstable". All Java releases are "stable", and the best one that gets all the fixes is always the latest version, even if some of those versions are only supported until the next version is out.

Footnotes

1. Within reason, sometimes tools have to catch up. ↩

[rarkins]

1. LTS awareness #27632 is relevant here and Java versioning would benefit. Treating non-LTS as "unstable" is a legacy concept
2. Most users do not want to be upgraded from LTS to non-LTS versions. Doing so should never be the default behavior for Renovate