Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strict version check constraint bug (or expected?) #242

Open
Diliz opened this issue Jun 13, 2024 · 4 comments
Open

strict version check constraint bug (or expected?) #242

Diliz opened this issue Jun 13, 2024 · 4 comments
Labels

Comments

@Diliz
Copy link

Diliz commented Jun 13, 2024

Hello!

I actually saw that the version constraint sometimes does not work as expected, as you can see here: https://go.dev/play/p/u1nq3v1-SiS

I got the following versions:

"1.0.0",
"1.0.0-beta.2"
"1.0.0-beta.1"
"1.0.0-alpha.2"
"1.0.0-alpha.1"
"1.0.0+toto.1"

here is a usable snippet:

	versions := []string{
		"1.0.0",
		"1.0.0-beta.2",
		"1.0.0-beta.1",
		"1.0.0-alpha.2",
		"1.0.0-alpha.1",
		"1.0.0+toto.1",
	}
	c, _ := semver.NewConstraint("= 1.0.0")
	for _, vs := range versions {
		v, _ := semver.NewVersion(vs)
		fmt.Println(v, c.Check(v))
	}

What I got:

1.0.0 true
1.0.0-beta.2 false
1.0.0-beta.1 false
1.0.0-alpha.2 false
1.0.0-alpha.1 false
1.0.0+toto.1 true

What I was expecting:

1.0.0 true
1.0.0-beta.2 false
1.0.0-beta.1 false
1.0.0-alpha.2 false
1.0.0-alpha.1 false
1.0.0+toto.1 false

If this was the expected behaviour:

  • how do I set a constraint that will work to have only the 1.0.0 matching here?
  • If not possible to match only 1.0.0 here, can we have a == constraint so that a really precise version could be set here?
@mattfarina
Copy link
Member

Please see the documentation on working with pre-releases as it explains the behavior you are seeing.

Many tools and libraries in this space require you to opt-in to using pre-releases. They do this out of experience in this space as pre-releases may (and sometimes) are not compatible with the stable release guarantees. The constraint needs to opt-in to pre-releases. You'll find the same behavior in other places like JavaScript and Rust.

@Diliz
Copy link
Author

Diliz commented Aug 26, 2024

For what is documented in the semver:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

What about this one:

<valid semver> ::= <version core> "+" <build>

How to identify builds from releases without build in it? Which have the exact same issue here.

@mattfarina
Copy link
Member

I will start with build metadata. The spec says...

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.

When comparing versions they are considered the same.

On pre-releases the spec states...

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.

In the past, this library did not opt-in for pre-releases and that caused problems. Many other tools opt-in to pre-releases.

Just because pre-release is a valid semver does not mean comparison systems MUST handle them along stable release versions by default. There is no spec for filtering tooling.

@yalosev
Copy link

yalosev commented Dec 16, 2024

@mattfarina Hello.
I have a linked question, so let more bother you in this thread, please.
My question is about prerelease versions. We couldn't compare a few prereleases of a one core version, that's understandable, but what about different core versions?

	c, _ := semver.NewConstraint("> 1.1.1")
	v, _ := semver.NewVersion("v2.2.2-alpha1")
	a := c.Check(v)
        // Output: false

meanwhile the constraint "> 1.1.1-0" gives the output true.

I guess, we can affirm, that the prerelease v1.1.1-XXXX satisfies two statements:

  1. v1.1.1-XXXX < v.1.1.1
  2. v1.1.1-XXXX > v1.1.0

What I might have missed in this logic?
Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants