Skip to content

Make the version suffix a valid semver pre-release identifier - #123

Open
Arshia001 wants to merge 1 commit into
mainfrom
fix/semver-valid-version-suffix
Open

Make the version suffix a valid semver pre-release identifier#123
Arshia001 wants to merge 1 commit into
mainfrom
fix/semver-valid-version-suffix

Conversation

@Arshia001

Copy link
Copy Markdown
Member

The bug

EDGE_VERSION_SUFFIX is a bare 7-char short SHA (CMakeLists.txt:35). When that SHA happens to be all digits with a leading zero, it parses as a numeric semver pre-release identifier — and semver forbids leading zeros on those. The version isn't merely unusual, it's invalid.

This fired for the first time on 0692402 (#121), short SHA 0692402. publish-nightly reached wasmer publish — the first time it had ever got that far, after 37b039c fixed the ./etc manifest bug — and was rejected at argument parsing:

error: invalid value '0.0.0-0692402' for '--version <PACKAGE_VERSION>':
       invalid leading zero in pre-release identifier

Re-running can't help: the same commit always yields the same SHA. It needs the short SHA to be all digits and start with zero — roughly 1 commit in 270 — which is why every previously published version (0.0.0-ad307e3, 0.0.0-8f4b341, 0.0.0-5ad7db6, 0.0.0-20bd0b8) got away with it.

The fix

Prefix with g, git-describe convention, so the identifier is always alphanumeric and can never be parsed as numeric.

Fixing it in CMake rather than sanitizing in the workflow keeps process.versions.edge itself valid semver. That matters because it's the single source of truth in three places:

  • both nightly workflows derive the published version from it (test-and-build-quickjs.yml:302, test-and-build.yml:302)
  • EDGE_DEFAULT_WASMER_PACKAGE (src/edge_compat_exec.cc:28) pins wasmer/edgejs@=EDGE_VERSION_STRING from the same macro

So the published version and the runtime pin shift together and stay consistent.

Behavior change

Versions now read 0.0.0-g<sha> instead of 0.0.0-<sha>. No test asserts the old shape. The registry will carry both forms across the cutover; already-published versions are untouched.

Test

Against wasmer 7.2.0 — the version CI installs — reproducing the parse-time rejection offline:

0.0.0-0692402    -> REJECTED: invalid leading zero in pre-release identifier
0.0.0-g0692402   -> accepted
0.0.0-gf1d02e4   -> accepted

And running the edited CMake block against the current tree:

-- COMMIT=f1d02e4
-- SUFFIX=-gf1d02e4

Context

Third distinct blocker in the chain that has kept nightlies red since 2026-06-30 — after the ./etc manifest bug (#120) and the gatsby external-fetch flake (#121). Note that #122 landing already gives main a letter-containing SHA (f1d02e4), so the next nightly would publish regardless. This PR is what stops it recurring on some future unlucky commit.

🤖 Generated with Claude Code

EDGE_VERSION_SUFFIX was a bare 7-char short SHA. When that SHA happens to
be all digits with a leading zero, it is a *numeric* semver pre-release
identifier, and semver forbids leading zeros on those — so the string is
not merely unusual, it is invalid.

This fired for the first time on 0692402 (#121), whose short SHA is
0692402. publish-nightly reached `wasmer publish` — the first time it had
ever got that far, after 37b039c fixed the ./etc manifest bug — and was
rejected at argument parsing:

  error: invalid value '0.0.0-0692402' for '--version <PACKAGE_VERSION>':
         invalid leading zero in pre-release identifier

Re-running cannot help, since the same commit always yields the same SHA.
It needs the short SHA to be all digits *and* start with zero, roughly 1
commit in 270, which is why every previously published version
(0.0.0-ad307e3, 0.0.0-8f4b341, 0.0.0-5ad7db6, 0.0.0-20bd0b8) got away
with it.

Prefix the suffix with "g", following the git-describe convention, so it
is always alphanumeric and can never be parsed as a numeric identifier.
Fixing it here rather than sanitizing in the workflow keeps
process.versions.edge itself valid semver — both nightly workflows derive
the published version from that value, and EDGE_DEFAULT_WASMER_PACKAGE
(src/edge_compat_exec.cc) pins wasmer/edgejs@=EDGE_VERSION_STRING from
the same macro, so the published version and the runtime pin shift
together.

Versions now read 0.0.0-g<sha> instead of 0.0.0-<sha>. No test asserts
the old shape.

Verified against wasmer 7.2.0, the version CI installs:

  0.0.0-0692402   -> rejected, invalid leading zero
  0.0.0-g0692402  -> accepted
  0.0.0-gf1d02e4  -> accepted

and by running the edited CMake block, which yields SUFFIX=-gf1d02e4.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant