Skip to content

fix(version): ignore SemVer build metadata and compare long numbers - #158

Merged
roxblnfk merged 2 commits into
fix/exact-prereleasefrom
fix/build-metadata
Oct 12, 2026
Merged

roxblnfk merged 2 commits into
fix/exact-prereleasefrom
fix/build-metadata

Conversation

@roxblnfk

@roxblnfk roxblnfk commented Oct 11, 2026 •

Copy link
Copy Markdown
Member

What was changed

  • Build metadata (+build.5, +5, +exp.sha.5114f85) follows the SemVer grammar on tags, binary output and constraints, after the number, a pre-release or a tail, and is ignored for ordering, stability and matching: >=1.2.3+build.5 parses again as it did in 1.18.0, and 1.2.3-beta.1+build.5 is 1.2.3-beta.1.
  • +… on a tag is always metadata: 1.2.3+beta is a stable 1.2.3 (it read as beta before), and 1.2.3+5-beta is 1.2.3 with metadata 5-beta. Version::$number no longer carries the metadata; dload show and the download log print the whole version a binary prints, pre-release and metadata included (1.2.3-rc.1+build.5).
  • Version numbers compare part by part as digit strings, so >1.99999999999999999998 accepts 1.99999999999999999999; version_compare is gone from Version.

Why?

Copilot's review of #155 found these after it was merged: metadata with letters was rejected in constraints and misread on tags, and long number parts compared as equal.

Review notes

  • Composer drops -dev from a lower bound that carries metadata, so ~1.0+build-7 rejects 1.0.0-RC1 there while ~1.0 accepts it; DLoad strips the metadata first, so both forms agree.

Checklist

  • Tested
    • Tested manually
    • Unit tests added
    • Full suite and psalm run locally
  • Documentation

fix(version): accept build metadata like `+build.5` in constraints again, as 1.18.0 did, and after a pre-release
fix(version): read `+…` on a tag as build metadata, so `1.2.3+beta` is a stable `1.2.3`

Build metadata follows the SemVer grammar: a plus, then dot-separated
identifiers of letters, digits and hyphens. It can come after the number,
a pre-release or a tail. It never changes order, stability, equality or
matching, and it stays only in the version string. `1.2.3+5-beta` is
`1.2.3` with metadata `5-beta`, and `1.2.3-linux+build.5` keeps the tail
`linux`. Version numbers now compare part by part as digit strings, so
parts too long for an integer no longer compare equal.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added bug Something isn't working tests labels Oct 11, 2026
`dload show` and the download log print the version with its pre-release and
build metadata, `1.2.3-rc.1+build.5` instead of `1.2.3`.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
@roxblnfk
roxblnfk merged commit fc7655f into fix/exact-prerelease Oct 12, 2026
5 checks passed
@roxblnfk
roxblnfk deleted the fix/build-metadata branch October 12, 2026 07:08
roxblnfk added a commit that referenced this pull request Oct 12, 2026
…158)

fix(version): accept build metadata like `+build.5` in constraints again, as 1.18.0 did, and after a pre-release
fix(version): read `+…` on a tag as build metadata, so `1.2.3+beta` is a stable `1.2.3`
fix(binary): show the whole version a binary prints, with its pre-release and build metadata

Build metadata follows the SemVer grammar on tags, binary output and constraints, and never changes order, stability or matching. Version numbers compare part by part as digit strings, so parts too long for an integer no longer compare equal.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
roxblnfk added a commit that referenced this pull request Oct 12, 2026
…158)

fix(version): accept build metadata like `+build.5` in constraints again, as 1.18.0 did, and after a pre-release
fix(version): read `+…` on a tag as build metadata, so `1.2.3+beta` is a stable `1.2.3`
fix(binary): show the whole version a binary prints, with its pre-release and build metadata

Build metadata follows the SemVer grammar on tags, binary output and constraints, and never changes order, stability or matching. Version numbers compare part by part as digit strings, so parts too long for an integer no longer compare equal.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant