You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My concern is clearly v2 incompatible with v1, but import "v1.3.1-0.20240210123610-ebeaf9415eb1" that will breaks minimal version selection since both version (v1.3.0 and v1.3.1-0.20240210123610-ebeaf9415eb1) has same major version.
Is this an issue for pkgsite or cmd/gp more generally?
I think this is working as intended, where a commit can have multiple identities, and while go generally relies on human convention to enforce semver/major version suffix matches for manual tags, all commits will have a an identity they can be imported as.
For a while, it was a well-known workaround to import prometheus this way (before it adopted the /v2 suffix).
My concern is clearly v2 incompatible with v1, but import "v1.3.1-0.20240210123610-ebeaf9415eb1" that will breaks minimal version selection since both version (v1.3.0 and v1.3.1-0.20240210123610-ebeaf9415eb1) has same major version.
Note that go mod tidy, go get -u, and similar operations prefer release versions over pseudo-versions — to add a dependency on a pseudo-version, you have to request its commit or pseudo-version explicitly. This pseudo-version behavior is fundamentally no different from accidentally introducing a bug or incompatibility during development.
And go get with the v2 release version shows an unambiguous error in this case:
$ go get github.com/ricoberger/script_exporter@v2.18.0
go: github.com/ricoberger/script_exporter@v2.18.0: invalid version: module contains a go.mod file, so module path must match major version ("github.com/ricoberger/script_exporter/v2")
Also note that there is nothing preventing the owner of the module from adding a tag like v1.4.0 to that same commit to make it unambiguously part of the v1 line — the go command has no way of knowing whether the problem is the v2.18.0 tag or the non-v2 module path in the go.mod file.
What is the URL of the page with the issue?
https://pkg.go.dev/github.com/ricoberger/script_exporter@v1.3.1-0.20240210123610-ebeaf9415eb1
What did you do?
https://github.com/ricoberger/script_exporter has released an valid version "v2.18.0" (commit id: ebeaf9415eb1) (just an example no offence)
However script_exporter's mod has no major suffix with "/v2", but github.com/ricoberger/script_exporter@v1.3.1-0.20240210123610-ebeaf9415eb1 is an valid "pseudo version" according to "mod spec"
My concern is clearly v2 incompatible with v1, but import "v1.3.1-0.20240210123610-ebeaf9415eb1" that will breaks minimal version selection since both version (
v1.3.0
andv1.3.1-0.20240210123610-ebeaf9415eb1
) has same major version.What did you see happen?
https://pkg.go.dev/github.com/ricoberger/script_exporter@v1.3.1-0.20240210123610-ebeaf9415eb1 is valid version
What did you expect to see?
No valid version if pseudo version related commit is after different major semver tag.
The text was updated successfully, but these errors were encountered: