Exact match on build metadata

[edouardhue]

Currently, the "build metadata" part of the version is ignored by all constraints. This make it impossible, in tools like Helm, to specifiy an exact dependency to a single build, and leads to unpredictable behaviour or hackish workarounds.

It has already been said in #172 and #164 that, per spec:

Build metadata MUST be ignored when determining version precedence.

I think this statement ignores the very first sentence of SemVer chapter 11 (emphasis is mine):

Precedence refers to how versions are compared to each other when ordered.

When using an exact match constraint (e.g. =1.0.0-develop+cafebabe or !=), no ordering nor precedence resolution is expected. I want this exact version, and expect an error if it does not exist. If, and only if, I use an inequality or range operator, should precedence rules come into play, as several versions may match the query.

[mattfarina]

While reading this I thought about 3 things I wanted to share...

1. chapter 11 also states "(Build metadata does not figure into precedence)".
2. Other semver packages (e.g., used by JavaScript, Rust, PHP, etc) ignore metadata. For example, if I use the js/npm semver package like so... $ semver -r "=1.2.3+build.1" 1.2.3 1.4.5 "1.2.3+build.1" it will simply ignore the +build.1 everywhere. It would find 2 versions that match. Build metadata is commonly ignored by the tools because it's metadata.
3. Some tools have checked the version to see if it matches a reference or tag and use that before passing it to the NewConstraint function and running a constraint check. It's possible for another tool to use what's provided here and layer on this feature.

As this is metadata, why should it be included?

[edouardhue]

@mattfarina I went through the past issues about build metadata here and in the SemVer spec (starting with semver/semver#77), I did not expect to fall into such a rabbit hole. Discussions did suggest at some point that build metadata could be used for cache busting and should be considered when testing for (in)equality, but this did not make it to the final spec. I'm rather going to take the point to SemVer, with the hope of having the subject definitely clarified in the spec.