adoptium
Not all versions returned in `available_releases` have a corresponding binary
Describe the bug For aarch64+mac (mac m2 devices), there is no release of feature version 8, which results in an inconsistency between the binary api and the available_releases api
Maybe add some filters to the available_releases api?
To Reproduce Steps to reproduce the behavior:
- Fetch the available releases from the
available_releasesapi - Use the version 8 returned to construct a new request for binary
- Make the request
- Get the 404 error
Expected behavior Either build the version or add filters to the available releases api
Device (please complete the following information):
- OS: MacOS
IIRC - There is no Java 8 binary for Mac OS X (Silicon) that we release, so this is a bug in our API filtering.
IIRC - There is no Java 8 binary for Mac OS X (Silicon) that we release, so this is a bug in our API filtering.
It is not a bug, the available_releases accurately returns the union of all release feature versions, with lts, most recent, and tip info. It doesn't take any parameters to specify the platform, or return any platform information - so you cannot assume all releases are available on all platforms (they are not).
Platform specific release information can be retrieved from, for example, the release_names request, e.g. for architecture=aarch64 and os=mac you can find the names for GA releases of a JDK via
curl -X 'GET' 'https://api.adoptium.net/v3/info/release_names?architecture=aarch64&os=mac&image_type=jdk&release_type=ga'
Calculating this page for an arbitrary set of user supplied filters would be potentially a comparatively expensive operation, and I am not sure if it offers a significant increase in functionality that other endpoints don't already make available, such as the /v3/info/release_names, /v3/info/release_versions or /v3/assets/feature_releases which can be used to determine if a version is available for a specific feature version.
Calculating this page for an arbitrary set of user supplied filters would be potentially a comparatively expensive operation, and I am not sure if it offers a significant increase in functionality that other endpoints don't already make available, such as the
/v3/info/release_names,/v3/info/release_versionsor/v3/assets/feature_releaseswhich can be used to determine if a version is available for a specific feature version.
An update to our API docs then?