cmd/go: unnecessarily multiple possible pseudo versions for one commit

[hajimehoshi]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11rc2 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hajimehoshi/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hajimehoshi/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/hajimehoshi/sdk/go1.11rc2"
GOTMPDIR=""
GOTOOLDIR="/Users/hajimehoshi/sdk/go1.11rc2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/hajimehoshi/gotest/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/b7/w11sqqrx7kx6fqfbn24wdsmh0000gn/T/go-build335252993=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Create a project repository with a main.go importing github.com/hajimehoshi/ebiten, and created go.mod. I tested 5 types of go.mod:

module example.com/m

require github.com/hajimehoshi/ebiten v0.0.0-20180819111657-1c088dc8b6d3

module example.com/m

require github.com/hajimehoshi/ebiten v1.0.0-20180819111657-1c088dc8b6d3

module example.com/m

require github.com/hajimehoshi/ebiten v1.7.0-alpha.0.20180819111657-1c088dc8b6d3

module example.com/m

require github.com/hajimehoshi/ebiten v1.8.0-alpha.0.20180819111657-1c088dc8b6d3

module example.com/m

require github.com/hajimehoshi/ebiten v1.9.0-alpha.0.20180819111657-1c088dc8b6d3

Run go1.11rc2 mod tidy with each go.mod

What did you expect to see?

go mod tidy should update the dependency version to v1.8.0-alpha.0.20180819111657-1c088dc8b6d3 since there is a tagged commit v1.8.0-alpha

What did you see instead?

In any cases, go mod tidy didn't update go.mod.

I think especially the case of v1.9.0-... seems dangerous since it might pollute the cache and when I release the version v1.9.0-*, the cache might not work well.

[bcmills]

Note that, in general, a given commit can correspond to multiple tagged versions too: nothing stops you from, say, tagging the same commit as all of v1.8.5, v1.9.0-rc1, and v1.9.0.

[hajimehoshi]

OK, so I fixed the issue title. Thanks!

[thepudds]

I think https://golang.org/cl/174061 would help this as well (by making it deterministic by selecting the semantically highest tag when it first creates a pseudo-version).

However, is part of the complaint here that a human can manually enter different pseudo-versions, and/or that different go.mod files over time might have different pseudo-versions for the same commit if tags are added over time to a single commit?

[thepudds]

@hajimehoshi In your example that you reported here, is it the case that most of the pseudo-versions you tried had the "wrong" semver tag within them for that same commit 1c088dc8b6d3 you kept using, but then go mod tidy did not update those "wrong" pseudo-versions to have correct semver tag within the pseudoversion?

@bcmills Would it be reasonable for go mod tidy to be defined to reach back to the source for any pseudo-version found in go.mod to pick the semantically highest semver tag contained within that commit and update the corresponding pseudo-version within the go.mod? Or at least for go mod tidy to do that update if the pseudo-version found in go.mod has a "wrong" semver tag within it?

CC @rogpeppe

[hajimehoshi]

but then go mod tidy did not update those "wrong" pseudo-versions to have correct semver tag within the pseudoversion?

As far as I remember, correct. Let me double-check later.

[bcmills]

@thepudds, I don't think go mod tidy is the right place for that. (It shouldn't hit the network if the module graph and the package graph are already in alignment and the required modules are already in the local cache.)

We also can't reject versions that are arbitrarily below that implied by parent tags. The same commit may be (for example) tagged as v1.3.0 and v1.2.1 (if it is, say, released as v1.3.0 and subsequently determined to fix a regression in v1.2.0), so it should be possible to name a commit based on any tag it may logically succeed.

However, we probably should reject (that is, refuse to even resolve) pseudo-versions that are above that implied by the highest tag, since that would allow modules to forcibly downgrade dependencies by misrepresenting the version of an old commit.

[gopherbot]

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