Accept Temurin four field versions with build metadata

[Hashim1999164]

Fixes #1270

Temurin publishes versions like 26.0.2.1+1. normalizeVersion only rewrote pure four field strings (e.g. 18.0.1.1), so those values failed the SemVer check on setup-java 6.x.

convertVersionToSemver now folds the extra numeric fields into SemVer build metadata and keeps any existing +build suffix (26.0.2.1+1 -> 26.0.2+1.1). normalizeVersion matches the same pattern.

Test plan

• npm test -- --testPathPatterns=util.test --coverage=false
• npm test -- --testPathPatterns=base-installer.test --testNamePattern=normalizeVersion --coverage=false
• npm run build

[johnoliver]

This might be over engineering, but according to JEP322 there is no limit on how many numbers there can be in a version, not sure how much work it would be to just allow any arbitrary number of numbers.

[brunoborges]

@johnoliver @Hashim1999164 I wonder if we should allow major version and full version only. Example: 26 matches latest 26. Any other 26.<something>... has to match the exact version.

Thoughts?

[Copilot]

Copilot review overview

🟡 Changes recommended

Temurin validation and candidate matching do not consistently normalize four-field versions with build metadata.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Normalize four-field versions before enforcing Temurin JMOD restrictions · New

What changed in this PR

Adds support for Temurin four-field versions with build metadata, such as 26.0.2.1+1.

Changes:

• Extends SemVer conversion and normalization.
• Updates bundled setup and cleanup artifacts.
• Adds utility and installer regression tests.

File	Summary
src/​util.ts	Adds build-metadata-aware version conversion.
src/​distributions/​base-installer.ts	Applies four-field normalization; moderate issues remain in pre-validation, JMOD gating, and candidate matching.
dist/​setup/​index.js	Updates the bundled utility.
dist/​setup/​242.index.js	Updates the bundled installer.
dist/​cleanup/​index.js	Updates the bundled utility.
__tests__/​util.test.ts	Adds conversion coverage.
__tests__/​distributors/​base-installer.test.ts	Adds normalization coverage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Hashim1999164]

@brunoborges @johnoliver yeah i was just trying to make the four field temurin builds like 26.0.2.1+1 actually resolve instead of getting tossed. major only (26) plus exact full string feels fine to me if thats what yall prefer. arbitrary length jep322 versions idk how deep that rabbit hole goes in the installer matching code bro i dont know that lmao. happy to slim the matcher if you want major + exact only.

[Hashim1999164]

@johnoliver @brunoborges pushed a follow up so the jmods gate normalizes four field versions that already have +build the same way JavaBase does. also clarified the 26.0.2.1+1 -> 26.0.2+1.1 fold order in the util test. still happy to slim matching to major + exact full string if thats the direction yall want.

[Hashim1999164]

@brunoborges @johnoliver any update? four field +build jmods gate fix is up, curious where yall landed on major-only vs exact full version matching

[michalporuban450-cyber]

Opravy #1270

Temurin publikuje verzie ako 26.0.2.1+1. normalizeVersioniba prepísať čisté štyri poľné struny (napr. 18.0.1.1), takže tieto hodnoty zlyhali v kontrole SemVer na nastavenie-java 6.x.

convertVersionToSemverteraz zloží ďalšie číselné polia do SemVer vybudovať metadáta a udržať všetky existujúce +buildprípona ( 26.0.2.1+1-> 26.0.2+1.1) ) normalizeVersionZhodujú sa s rovnakým vzorom.

Skúšobný plán

* `npm test -- --testPathPatterns=util.test --coverage=false`

* `npm test -- --testPathPatterns=base-installer.test --testNamePattern=normalizeVersion --coverage=false`

* `npm run build`

3Fixes #1270

Temurin publishes versions like 26.0.2.1+1. normalizeVersion only rewrote pure four field strings (e.g. 18.0.1.1), so those values failed the SemVer check on setup-java 6.x.

convertVersionToSemver now folds the extra numeric fields into SemVer build metadata and keeps any existing +build suffix (26.0.2.1+1 -> 26.0.2+1.1). normalizeVersion matches the same pattern.

Test plan

• npm test -- --testPathPatterns=util.test --coverage=false
• npm test -- --testPathPatterns=base-installer.test --testNamePattern=normalizeVersion --coverage=false
• npm run build

[johnoliver]

Ok, digging a bit deeper on this—please correct me if I have misunderstood the history:

• Java version 18.0.1.1 not supported as input value #326 initially reaffirmed the SemVer-based input model and suggested representing the exact Java version 18.0.1.1 as 18.0.1+1.
• PR Support multi-field Java versions like 18.0.1.1 #1092 later added compatibility for exact multi-field JEP 322 inputs by normalizing them internally; for example, 18.0.1.1 becomes 18.0.1+1.

So the accepted input syntax is now broader than strict SemVer, while SemVer-compatible strings remain the common internal representation used for matching and comparison. This leaves a design question about how far we want to support JEP 322 syntax—especially whether multi-field versions should be supported only as exact inputs, or whether ranges also need defined semantics.

It also raises a broader question about the internal model. Downstream APIs do not appear to use one consistent version format: some provide SemVer-like strings, others expose JEP 322-like versions, and others provide structured fields or vendor-specific tags that we normalize before matching. SemVer gives us a shared comparison mechanism, but mapping JEP 322’s additional numeric fields into SemVer build metadata is an adaptation rather than a native representation of Java version semantics.

I am fine with this PR because it fixes the current regression and is consistent with the compatibility direction introduced in #1092. Separately, it may be worth deciding whether the long-term design should continue to use SemVer as the internal version model, or introduce a Java-version representation that preserves JEP 322 fields and defines conversion/range behavior explicitly.