404 Not Found for /v3/assets/version/21.0.2+13

[rednoah]

The /v3/assets/version endpoint does not work for the latest 21.0.2+13 release:

curl -I 'https://api.adoptium.net/v3/assets/version/21.0.2+13'
HTTP/1.1 404 Not Found

21.0.2+13 is listed on the website:
https://adoptium.net/en-GB/temurin/releases/?version=21&package=any

The endpoint does however work for previous releases

curl -I 'https://api.adoptium.net/v3/assets/version/20.0.2+9'
HTTP/1.1 200 OK

curl -I 'https://api.adoptium.net/v3/assets/version/17.0.10+7'
HTTP/1.1 200 OK

[johnoliver]

The version is 21.0.2+13-LTS, i.e:

https://api.adoptium.net/v3/assets/version/21.0.2+13-LTS

easiest way to find the version is from:

https://api.adoptium.net/v3/info/release_versions?version=[21,22]&release_type=ga

[karianna]

The version is 21.0.2+13-LTS, i.e:

https://api.adoptium.net/v3/assets/version/21.0.2+13-LTS

easiest way to find the version is from:

https://api.adoptium.net/v3/info/release_versions?version=[21,22]&release_type=ga

Do we still see this as a bug @johnoliver or an update to our docs?

[lemeurherve]

FTR, that was not fun to debug why assets could not be returned from a valid version working elsewhere with the API 😓

IMO /assets/version/<...> should be coherent with other paths like https://api.adoptium.net/v3/installer/version/<...> that don't require this -LTS additional info (not necessarily already available).

https://api.adoptium.net/v3/assets/version/21.0.1%2B12?architecture=x64&image_type=jdk returns a 404 error
https://api.adoptium.net/v3/installer/version/jdk-21.0.1%2B12/windows/x64/jdk/hotspot/normal/eclipse?project=jdk returns a MSI installer without requiring any bit about the fact this version is a LTS or not.

[johnoliver]

the version in the installer path:

https://api.adoptium.net/v3/installer/version/jdk-21.0.1%2B12/windows/x64/jdk/hotspot/normal/eclipse?project=jdk

is the release name/tag jdk-21.0.1+12 and not the version:

https://github.com/adoptium/temurin21-binaries/releases/tag/jdk-21.0.1%2B12

If anything this is actually a badly named path as it makes it seem like that is a version and not a name...something for v4

There is:

https://api.adoptium.net/v3/assets/release_name/eclipse/...

That will behave the same as the installer path as it takes a release name.

Re the -LTS, and 21.0.1+12 being a valid version. So the version of the binary that Temurin released IS 21.0.1+12-LTS, it is what is in the binaries metadata and if you run java -version what is returned. I accept that Temurin have changed their naming format adding the -LTS and that this has caused confusion here, and that in general when people discuss Java versions they pretty much ignore the -LTS. But the version containing -LTS is in accordance with https://openjdk.org/jeps/322

If a release is part of a series of releases for which an implementor offers long-term support then the 
value of $OPT should start with "LTS", e.g., 11.0.2+13-LTS

The question here would be when we say an argument is a version should it be an exact match (which is how we have interpreted it to date), or introduce something more fuzzy where we effectively say "well if the user asked for 11.0.2+13, what they REALLY mean is 11.0.2+13-LTS".

So there is some precedence for modifying the version style as there is the semver flag:

https://github.com/adoptium/api.adoptium.net/blob/main/adoptium-frontend-parent/adoptium-api-v3-frontend/src/main/kotlin/net/adoptium/api/v3/routes/info/ReleaseListResource.kt#L126

That allows the user to specify versions as a semver rather than openjdk version.

So my options would be:

• Keep the matching as is, but make it clear to users that version means an exact version, and that -LTS has been added recently
• Make the matching less exact and effectively make x.y.z == x.y.z-LTS, presumably only for GA versions
• Add a flag/option that users can add that allows them to choose their behaviour...version_match=IGNORE_LTS?

[karianna]

I think I'd go for option 3 & 2 - that is, have the version_match behaviour flag but default it to the principle of least surprise where semver == semver-LTS for GA releases.

[tellison]

I tend to disagree with that approach @karianna , I think the API usage should be data-driven and users should not presume or assume the values in the API URLs. The API users (programs/scripts/etc) should be reactive to the results obtained from earlier root API queries. Of course, documenting the behavior of the APIs and explaining their structure is good so that the APIs used to achieve a task are navigable. I'm not a fan of aliases or fuzzy matching API URLs.

So when the original post says (and I paraphrase), "21.0.2+13 is listed on the website" so I tried "https://api.adoptium.net/v3/assets/version/21.0.2+13" and it doesn't work, I think that is flawed logic. Don't guess a URL based on the website display, use the supplied info/release_versions API to get the list, and so on.

Our documentation is lacking for the API for sure.

[karianna]

Yeah it's a tough one, we could update the docs for sure as a starting point and see how many people still trip after that (which would tell me our design is not intuitive to use).