Version with prerelease and Constraint without it - Comparison fails even in simple cases

[Tiago Kramer Vieira]

According to the README.md, when you want to use prerelease comparison, -0should be append in the end of the sem. version in constraint, but the case where I still do not want prerelease comparison but the version includes it, is misleading.

Example:

versionConstraint, err := semver.NewConstraint(">= 1.0.0")
if err != nil {
	return false, err
}

currVersion, err := semver.NewVersion("2.0.0-alpha")
if err != nil {
	return false, err
}

fmt.Println(versionConstraint.Check(currVersion))

The last command prints false, even though discarding the prerelease is should result in true.

Expected behavior:
When using constraint comparison, when using prerelease as input for verification, I would expect that the prerelease is discarded and the whole version is matched.

[Łukasz Mierzwa]

Looks like I'm hitting a problem where semver.NewConstraint(">=0.17.0") doesn't pass for 0.19.0-rc.0 which according to https://regex101.com/r/Ly7O1x/3/ should be a valid semver.

[Matt Farina]

I would expect that the pre-release is discarded and the whole version is matched.

The pre-release is not a part of the version but a type for the whole version. The whole 2.0.0-alpha is the pre-release not just the alpha portion of it.

Per the spec:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

This saying that the way to mark the version [whole version] as a pre-release is by using a hyphen and then a pre-release identifier.

What you are asking for breaks from the specification and the way it is widely implemented.

[Matt Farina]

@prymitive This is where semantic versioning gets complicated.

From the spec:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

This means a pre-release may break from API compatibility from the release. For example, 0.19.0-rc.0 could break from API compatibility with 0.19.0. I imagine it is unlikely but it could happen and the spec allows for it. The spec allows for a pre-release to, for example, add a new API and then have it change before the final release comes out. The pre-release may not be compatible with any stable release.

There are two methods to doing range comparisons in this library. One is more conservative than the others.

• semver.Constraint filters out pre-releases unless the constraint is searching for pre-releases. This is the same behavior found in other systems like the JS equivalent used by NPM.
• semver.Version.Compare includes pre-releases in all cases. It does not have limiters on the range (e.g., ^, ~, etc).

[Łukasz Mierzwa]

Thanks for details, I have a fairly simplified case and I think that I can safely strip -rc.0 part away before checking contrains. Although I might look at semver.Version.Compare if that proves to be insufficient or incorrect. Thanks!

[Matt Farina]

Closing as conversation about a year ago.