Single version constraint does not allow prerelease

[rubenvereecken]

According to https://jubianchi.github.io/semver-check, the following is valid:

However, when I try this using pub_semver, I get that the prerelease version is not compatible with the constraint:

// prints fales
print(VersionConstraint.parse('1.0.56').allows(Version.parse('1.0.56-beta.4')));

[sigurdm]

I somewhat agree that this is different from how I read https://semver.org/spec/v2.0.0-rc.1.html#spec-item-10 .

Pre-release versions satisfy [...] the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

I don't think we should change how we interpret this. The spec does not really tell us anything else about "constraints" and what it means to "satisfy".

We should probably document how our constraints work to avoid confusion.

@jonasfj might have more opinion here :)

[jonasfj]

It's unclear to me that semver specifies what a version range is.

Pub uses semantic Versioning spec version 2.0.0-rc.1, which as far as I can read it provides a total ordering of all version numbers.

Precedence MUST be calculated by separating the version into major, minor, patch, pre-release, and build identifiers in that order. Major, minor, and patch versions are always compared numerically. Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.

from https://semver.org/spec/v2.0.0-rc.1.html#spec-item-12

---

pub_semver has a section in the README, titled "Pre-release versions are excluded from most max ranges.".

This is the closest to a formal specification of version ranges we have.

I generally understand it as:

• >=1.2.3 <2.0.0 means v is satisfied if v >= 1.2.3 and v < 2.0.0-0
• >=1.0.0-dev <2.0.0 means v is satisfied if v >= 1.0.0-dev and v < 2.0.0-0
• >=1.2.3 <2.0.0-dev means v is satisfied if v >= 1.2.3 and v < 2.0.0-dev
• ^1.2.3 means v is satisfied if v >= 1.2.3 and v < 2.0.0-0
• 1.2.3 means v is satisfied if v >= 1.2.3 and v < 1.2.3 (also meaning that v = 1.2.3).

It's possible that we should distill this into a formal specification. But a long with the total precedence ordering from Paragraph 12 from Semantic Versioning version 2.0.0-rc.1, I think this is sound and reasonably unsurprising.

If anything the documentation would probably benefit from more examples, rather than a formal specification.

---

Regardless, my point would be that https://jubianchi.github.io/semver-check/#/ probably doesn't understand pub_semver.

[sigurdm]

If anything the documentation would probably benefit from more examples, rather than a formal specification.

Big +1 for clarifying examples!

Regardless, my point would be that https://jubianchi.github.io/semver-check/#/ probably doesn't understand pub_semver.

I think that whatever some tool is doing is besides the point that the quoted part of https://semver.org/spec/v2.0.0-rc.1.html#spec-item-10 could be interpreted as pre-release versions satisfying the constraints, and that is not what we do in pub_semver. We'd better clarify that in the pub_semver docs. (And actually I'm really curious what that sentence is supposed to mean if not exactly that).

Fwiw. I don't think we should change our semantics, just the docs, and examples would be plenty good here.