Should publishes with versions only differing in metadata be allowed?

[sfackler]

For example, https://crates.io/crates/openssl-src has 110.0.0 and 110.0.0+1.1.0f, which are semver-equivalent since build metadata doesn't affect the actual version. It seems like this probably shouldn't be allowed?

[mbrubeck]

Some previous discussion in dtolnay/semver#107

[carols10cents]

Sure sounds like we should be disallowing versions like these that only differ in build metadata....

[jeikabu]

Looks like I fell victim to this.

I'd been using semver metadata only to discover it doesn't work as expected. Rather than getting rid of metadata support it would make sense to let them be semver equivalent. Whether some attempt is made to parse and make sense of the metadata is a convention that could be developed separately. Until then taking the most recent would be the "least surprising".

To me the primary use case is crates that have some external, non-crate dependency and you want to mirror it's semver version. "sys" crates fall in this category. I have a crate that corresponds to NNG 1.1.1. Being able to version my crate as 1.1.1 instead of some unrelated version scheme that requires mapping between the two is the simplest. If I need to alter crate contents in some way (e.g. packaging or documentation- some non-API-breaking change) 1.1.1+SOMETHING would make the most sense.

As it is, if you have a crate versioned 0.1.0+XYZ and you then publish/yank 0.1.0 the crate is "yanked" even when there's a semver-equivalent crate available, 0.1.0+3.

[sgrif]

I really do think this just boils down to a bug in semver. Build metadata is ignored for precedence, but that does not mean it's ignored for equality. To me this implies that if two versions differ only in metadata, we may select one at random to treat as the "latest version", but they are still different versions, and should be treated as such both by crates.io and Cargo. I laid out some further reasoning in dtolnay/semver#107 (comment)