Versions that start with v2 or later don't belong to the same module as v0 or v1 versions. They would belong to gitlab.example.com/my/pkg/v2. The major version suffix is required.

We should provide a clear diagnostic message for this.

This might be a duplicate of #30499. (Not entirely clear to me whether the problems occur under the same conditions.)

@tbpg is working on this, but I'm not able to assign it to him.

Change https://golang.org/cl/174180 mentions this issue: cmd/go: error if mismatched major versions causes use of pseudo-version

Change https://golang.org/cl/173721 mentions this issue: cmd/go: error if mismatched major versions causes use of pseudo-version

prometheus/prometheus#5356 (comment) is an interesting counter-point to this issue: it appears that some maintainers are already intentionally using mismatched module paths to avoid SemVer semantics for not-actually-SemVer repositories.

That said, it seems like the pseudo-version we choose in that case should be based on the last v1.*.* tag, not the v0.0.0 prefix that we're seeing today. (Perhaps the observed behavior for prometheus — and possibly for @firelizzard18's example in this issue — is another instance of #27171?)

Since CL 181881, we now print an error message like this:

$ GOPROXY=direct go list -m rsc.io/quote@v3.0.0
go get rsc.io/quote@v3.0.0: rsc.io/quote@v3.0.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3

Note that proxy.golang.org is still serving results based on go1.12 behavior (#32805), and we don't print this message for results received from the proxy. We probably should.

we don't print this message for results received from the proxy. We probably should.

That is tracked separately as #31428.

I believe this is resolved. @firelizzard18, please let us know if this is still an issue for you using Go 1.13.