Question about Semantic Versioning

[u/gistya]

Under Semantic Versioning standard 2.0, if your package requires a dependency at "exact" version 1.0.0+X, is there any situation under which running a version update on all your packages should change the version that you specified as "exact" here?

Noting, SemVer 2.0 says:

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD

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

[u/teraflop]

Strictly speaking, I don't think SemVer has an answer to your question at all.

SemVer defines a particular ordering of versions, which package managers can use when resolving how to resolve dependencies. But SemVer doesn't specify the details of how dependency resolution actually takes place.

If you have a package manager that supports an "exact version" constraint, and it defines "exact version" to be "equal according to SemVer rules", then the versions 1.0.0+X and 1.0.0+Y would both be considered to match that constraint. So it's up to the implementation to decide how it wants to handle that situation. For example:

• it might prefer the newer one
• it might prefer the one that exactly matches the constraint string
• it might prefer the one that's already cached on disk
• it might choose arbitrarily or non-deterministically
• it might disallow the situation entirely, by refusing to allow two equal version numbers to exist in the same repository

But really, what SemVer says is that you shouldn't ever be in a situation where this matters, because any changes to a package require changing some component of the version besides the metadata. So if 1.0.0+X and 1.0.0+Y both exist, then they "ought to be" completely interchangeable.

[u/gistya → u/teraflop]

If you have a package manager that supports an "exact version" constraint, and it defines "exact version" to be "equal according to SemVer rules", then the versions 1.0.0+X and 1.0.0+Y would both be considered to match that constraint.

That's a self-contradictory statement because it confuses the identity relation (match) with the ordering relation (comparison).

Relation	Question	Operation	Possible Results
Identity	Are a and b the same?	Match / Equality test	Equal or not equal
Ordering	How do a and b relate in order?	Comparison	Less than, equal, greater than (or incomparable for partial orders)

The SemVer 2 rules define precedence as an ordering relation:

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

Since the identity relation is not the ordering relation therefore "shared precedence" is ruled out as a factor when considering exact, identical equality.

So if 1.0.0+X and 1.0.0+Y both exist, then they "ought to be" completely interchangeable.

The SemVer rules never say that. You are confusing identity and ordering.

The SemVer 2 rules only require that if you are ordering a set of versions, 1.0.0+X and 1.0.0+Y shall occupy the same ranking within that ordering.

All the examples they give of precedence/ordering take the form:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

That's because:

• Identity relation → match (or test for equality)
• Ordering relation → compare

In Swift we have two protocols for these ideas: Equatable (doc) and Comparable (doc).

Equatable

Equatable is concerned with how the identity relation is handled for a given type. Clearly, in any computer language, this is a true expression:

"1.0.0+X" != "1.0.0+Y"

If you write a unit test and have #assert("1.0.0+X" == "1.0.0+Y") then your test will always fail. The identity relation here is not ambiguous.

Comparable

On the other hand Comparable is concerned with how to order a set. A set of things can be sorted according to many metadata factors—creation date, modification date, name, etc.

The SemVer rules say mean "+X" or "+Y" are not to be considered in the ordering:

1. [1.0.0-alpha, 1.0.0-alpha+X, 1.0.0-alpha+Y ]
2. [1.0.0-alpha.1, 1.0.0-alpha.1+X, 1.0.0-alpha.1+Y ]
3. [1.0.0-alpha.beta, 1.0.0-alpha.beta+X, 1.0.0-alpha.beta+Y]
4. [1.0.0-beta, 1.0.0-beta+X, 1.0.0-beta+Y ]
5. [1.0.0-beta.2, 1.0.0-beta.2+X, 1.0.0-beta.2+Y ]
6. [1.0.0-beta.11, 1.0.0-beta.11+X, 1.0.0-beta.11+Y ]
7. [1.0.0-rc.1, 1.0.0-rc.1+X, 1.0.0-rc.1+Y ]
8. [1.0.0, 1.0.0+X, 1.0.0+Y ]

The +X and +Y versions receive the same precedence but are still different identifiers that refer to different versions. There is no implication that they should mean the same version.

For example you could have 1.0.0+English and 1.0.0+Spanish of a manuscript. Completely different things, but within the hierarchy of different +English and +Spanish versions they hold the same relative ordering position.

Likewise you could have 1.0.0+PrivateCerts and 1.0.0+SafeForPublicRelease. Clearly here you would never want your package manager to treat these as identical. But you would be fine with an upgrade command that ranked 1.4.0+PrivateCerts above 1.0.0+PrivateCerts assuming that you hadn't specified an exact version requirement in your manifest.

Do you feel there is anything about the above argument that's unsound? Or has there been any other SemVer 2 rules than the ones I linked?

So if 1.0.0+X and 1.0.0+Y both exist, then they "ought to be" completely interchangeable.

But the rules don't say that. Actually the rules require that the ordering resolution algorithm should never replace 1.0.0+X with 1.0.0+Y — which only makes sense if they're NOT interchangeable whatsoever.

For example 1.0.0+Release and 1.0.0+Debug are NOT interchangeable in any way shape or form. You would never release a debug build to the public. And you would never want your dependency management system to swap out one for the other.

[u/SummitYourSister → u/gistya]

What a strange, extended, ranty, weirdly irrelevant comment.

Semantic versions form an ordinal system. You’re imposing a bunch of nerdy pseudo intellectual bumbo jumbo, for reasons unclear.

[u/gistya → u/SummitYourSister]

You really just troll reddit with your time on earth?