Dup of #27171, but we should make sure the tests cover this case.

This might not be an exact duplicate of #27171, since it also interacts non-trivially with v2 and +incompatible.

At current head:

$ go list -f '{{.Version}}' -m github.com/sylr/prometheus@v2.9.2+sylr.2
go: finding github.com/sylr/prometheus v2.9.2+sylr.2
v0.0.0-20190510132036-085fc219838d

It should instead be something like

v2.9.3-0.20190510132036-085fc219838d+incompatible

(CC @sylr)

It should instead be something like

v2.9.3-0.20190510132036-085fc219838d+incompatible

For readability it would be nice if the tag would be kept in the go.mod -> v2.9.2+sylr.2+incompatible

For readability it would be nice if the tag would be kept in the go.mod

That's (an interesting special case of) #25898.

FWIW, from looking at this somewhat briefly (and hence might not be correct), it seems this issue is specific to a v2+ module and asking for a commit (current meaning of @master in this case) where the most recent semver tag at that commit is for a different major version than the major version in the go get request. I had a slightly longer write up in #27171 (comment) (along with some links to the possibly corresponding code). Partial quote from that comment:

In #29262, rsc.io/quote at master has two different major versions following the Major Subdirectory approach. It has a v1 module in the root of the repo, and a v3 module in a /v3 subdirectory. If you ask for go get rsc.io/quote@master, that is asking for v1 of rsc.io/quote, which is a valid request, but the most recent tag on master matching that glob pattern ends up being v3.0.0, which I think is what is returned by RecentTag. The v3 is not what is desired, and the caller gives up and falls back to a v0.0.0- pseudo version (probably here). This could be viewed as a variation of 1., or could be viewed as a separate problem.

I suspect but have not confirmed that this particular problem pattern would not happen for someone following the "Major Branch" approach for a v2+ module with different branches for v1 vs v2 vs v3 with the appropriate semver tags on their respective branches.

CC @rogpeppe

It should instead be something like

v2.9.3-0.20190510132036-085fc219838d+incompatible

That commit actually has a go.mod file, and the module path it declares is github.com/prometheus/prometheus.

However, the +incompatible suffix is generally not allowed in conjunction with a go.mod file: the +incompatible suffix is intended only for projects predating modules, not as an ongoing bypass for versioned import paths. That probably means that we should use the highest tag matching the path (v1.8.2) as the base for the pseudo-version, rather than the v2.[…] tag with the +incompatible suffix.

It also means I need to find a different example for +incompatible pseudo-versions. 😞

Change https://golang.org/cl/181881 mentions this issue: cmd/go: validate pseudo-versions against module paths and revision metadata