Builds get their precedence back
2.0.0-rc.2 turned builds into inert "build metadata," so every build of a version counted as equal. This puts the rc.1 behaviour back: a build takes part in precedence and sorts above the plain release.
Proposal
Semantic Versions ships as its own 1.0.0, but the ambition is
bigger than that. We think it makes a good candidate for the next version of
Semantic Versioning: the
3.0.0 that semver.org never got around to. Either way the spec stands on its
own, so you can pick it up today whether or not that ever happens.
What we're proposing
There is not much here, and that is the point. Anything valid under Semantic Versioning 2.0.0 is still valid and parses the same way. The changes either put back meaning that a later draft stripped out, or write down the parts everyone was already using without a spec to point at.
2.0.0-rc.2 turned builds into inert "build metadata," so every build of a version counted as equal. This puts the rc.1 behaviour back: a build takes part in precedence and sorts above the plain release.
A patch is a fix for behaviour that was never meant to happen, not a promise of backward compatibility (which nothing can really guarantee). A fix stays a fix.
Comparators, comparator sets, hyphen ranges, x-ranges, tilde, caret and the approximate operator (~>) all get defined, so two tools stop reading the same range two different ways.
Where it stands
We are realistic about the odds. Semantic Versioning 2.0.0 has not
meaningfully changed in over a decade and there is no obvious route to a
3.0.0, so there is no guarantee the maintainers at
semver.org take any of
this on. That is the whole reason Semantic Versions has its own name and
its own version: it is a finished spec you can use right now, with a
reference parser
to match. If the proposal goes somewhere, it is the basis for 3.0.0. If it
does not, nothing here changes and you can still build on it.