x/pkgsite: inconsistency major version between pseudo version and base version

[mengzhuo]

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 and v1.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.

[seankhliao]

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).

cc @bcmills

[mengzhuo]

I think this is a pkgsite(proxy) issue since bad version will be generate go.mod and zip (https://proxy.golang.org/github.com/ricoberger/script_exporter/@v/v1.3.1-0.20240210123610-ebeaf9415eb1.mod), which can be download by non-go tools like curl, etc.

[bcmills]

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.

[bcmills]

Also note that https://pkg.go.dev/github.com/ricoberger/script_exporter@v1.3.1-0.20240210123610-ebeaf9415eb1 displays a Go to latest button that leads to v1.3.0 — so it is also directing users to the released version rather than a pseudo-version.