Repository navigation
Prefer Zulu 4-segment hotfix builds when resolving version ranges - #1278
Merged
Merged
Conversation
Azul reports hotfix releases like 25.0.4.1 as java_version=[25,0,4,1] with openjdk_build_number=1 (SDKMAN '25.0.4+1.1'). Sorting candidates via semver.compareBuild ranked 25.0.4+7 above 25.0.4+1.1, so ranges such as '25' resolved to the older build. Compare java_version, build number and distro_version numerically instead. Fixes: #1275 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused implementation matches the documented ordering requirements and includes regression coverage for exact and ranged versions.
Review effort: Balanced
Findings: None
What changed in this PR
Updates Zulu version resolution so range requests prefer newer four-segment hotfix builds.
Changes:
- Sorts candidates numerically by Java version, build number, then distro version.
- Adds coverage for exact and ranged hotfix resolution.
- Rebuilds the runtime bundle.
| File | Description |
|---|---|
src/distributions/zulu/installer.ts |
Implements numeric candidate ordering. |
dist/setup/978.index.js |
Updates the generated runtime bundle. |
__tests__/util.test.ts |
Covers SDKMAN Zulu version parsing. |
__tests__/distributors/zulu-installer.test.ts |
Tests hotfix selection behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description:
Azul publishes out-of-band hotfix builds with a 4-segment
java_version. For example,zulu25.36.205-ca-jdk25.0.4.1hasjava_version=[25,0,4,1]andopenjdk_build_number=1. SDKMAN calls this build25.0.4+1.1.Since the v6 Azul Metadata API migration, an exact
25.0.4+1.1request (for example from.sdkmanrcjava=25.0.4+1.1-zulu) already resolves. The failure in the issue came from a pinned pre-v6 commit that dropped the build number.There was still a bug with version ranges. Candidates were sorted with
semver.compareBuild, which compares the text after+and ranks25.0.4+7above25.0.4+1.1. As a result,25or25.0.4resolved to the older GA build instead of the newer 25.0.4.1 hotfix.This PR sorts Zulu candidates numerically by:
java_version(a missing segment counts as 0)openjdk_build_numberdistro_version, which stays the tie-breakerThe version strings themselves are unchanged, so exact matching and toolcache folder names behave the same.
Toolcache lookup of already-cached versions may have a similar ordering issue. It is not addressed here.
Related issue:
Fixes: #1275
Check list:
npm run checklocally (format, lint, build, test) and all checks pass.__tests__/distributors/zulu-installer.test.tsand__tests__/util.test.tspassed (284 tests).npm run buildpassed. ESLint on the changed source and Zulu test file was clean.