cmd/go: major version without preceding tag must be v0, not v1 - breaks build of github.com/go-check

[tamalsaha]

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

$ go version

go version devel +e9782bdebd Thu Aug 8 00:38:10 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/travis/.cache/go-build"
GOENV="/home/travis/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/travis/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/travis/.gimme/versions/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/travis/.gimme/versions/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/travis/gopath/src/gomodules.xyz/cert/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build463038650=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I am running my tests against go:tip in Travis. This is breaking build for external library.
https://travis-ci.org/gomodules/cert/jobs/569425585

What did you expect to see?

I expect the build to not break. This can be a warning not an error.

What did you see instead?

$ go build ./...
go: github.com/appscode/go@v0.0.0-20190808133642-1d4ef1f1c1e0 requires
github.com/flosch/pongo2@v0.0.0-20181225140029-79872a7b2769 requires
github.com/go-check/check@v1.0.0-20180628173108-788fd7840127: invalid pseudo-version: major version without preceding tag must be v0, not v1

[ianlancetaylor]

CC @bcmills @jayconrod

Are you suggesting that we should remove that check, or are you suggesting that github.com/go-check should fix their versioning?

[tamalsaha]

I am suggesting that Go should remove that check or make that a warning. I am sure there are more libraries that are out there which don't follow this rule.

[tamalsaha]

Here is another but seems related build break:

https://travis-ci.org/kmodules/monitoring-agent-api/jobs/569397065#L231

go: kmodules.xyz/client-go@v0.0.0-20190808141354-bbb9e14f60ab requires
	github.com/Azure/go-autorest/autorest@v0.7.0 requires
	github.com/Azure/go-autorest/tracing@v0.4.0 requires
	contrib.go.opencensus.io/exporter/ocagent@v0.4.6 requires
	github.com/census-instrumentation/opencensus-proto@v0.1.0-0.20181214143942-ba49f56771b8: invalid pseudo-version: version before v0.1.0 would have negative patch number
The command "go build -v ./..." exited with 1.

[jayconrod]

Sorry, this change is intentional. In Go 1.13, the Go command enforces pseudo-version validity more strictly. Among other reasons, this is necessary to prevent people from bypassing minimal version selection by using pseudo-versions like v1.999.999-20180628173108-788fd7840127. It's important that versions are under control of module authors. The change is explained in the Go 1.13 release notes.

If an invalid version appears in a go.mod file you control, you can replace it with a commit or branch name. For example, change

require github.com/go-check/check v1.0.0-20180628173108-788fd7840127

to

require github.com/go-check/check 788fd7840127

then run go mod tidy, which will update the go.mod with the equivalent pseudo-version.

If an invalid version appears in one of your dependencies (as is the case here), you can work around it with a replace directive:

replace github.com/go-check/check v1.0.0-20180628173108-788fd7840127 => 788fd7840127

then run go mod tidy.

[bcmills]

Note that these issues have already been fixed in their respective upstream repositories:
flosch/pongo2@bbf5a6c
census-ecosystem/opencensus-go-exporter-ocagent@472362a

It may require a bit of work to upgrade past the references to the invalid versions, but it should be possible — and you can patch them with replace directives in the meantime.

[tamalsaha]

If an invalid version appears in a go.mod file you control, you can replace it with a commit or branch name.

What do you mean by invalid version? I am using Go 1.12.7 on my development machine. This is how I got that version number. I add the following line:

require (
  github.com/go-check/check <commit_hash>
)

Then run go mod tidy. Go automatically writes that invalid version. So, what was auto generated by Go 1.12.7 is now considered invalid by Go 1.13?

Also, the original issue major version without preceding tag must be v0, not v1 seems unrelated in that case. What to do about that?

[bcmills]

What do you mean by invalid version?

See https://tip.golang.org/doc/go1.13#version-validation.

I am using Go 1.12.7 on my development machine. […] Go automatically writes that invalid version.

If you already had an invalid version in your module cache with Go 1.12, then it would erroneously use that version to satisfy new dependencies in other modules too. See #27171 and #27173.

Also, the original issue major version without preceding tag must be v0, not v1 seems unrelated in that case.

That is one of the many sub-cases of #27173. The replace workaround should work for that version as well.

[rhcarvalho]

@tamalsaha in the particular case of the Go code found in https://github.com/go-check/check, the canonical package import is gopkg.in/check.v1. If you use that import path with Go 1.13 (or any previous release), you should have no errors:

$ go1.13 get gopkg.in/check.v1
go: finding gopkg.in/check.v1 latest
go: downloading gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15
go: extracting gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15
go: downloading github.com/kr/pretty v0.1.0
go: extracting github.com/kr/pretty v0.1.0
go: downloading github.com/kr/text v0.1.0
go: extracting github.com/kr/text v0.1.0
go: finding github.com/kr/pretty v0.1.0
go: finding github.com/kr/text v0.1.0

[philippgille]

If you already had an invalid version in your module cache with Go 1.12, then it would erroneously use that version to satisfy new dependencies in other modules too.

I've got a repo with lots of modules and dependencies between those modules. I've also got a commit in the remote repo where versions in the go.mod file have an invalid pseudo version, which I only realized by trying to build all modules with Go 1.13 in addition to 1.12.7. I'm now trying to fix this. I deleted the local cached module, searched&replaced the invalid version string by the newest commit hash and ran go mod tidy on all modules. Some entries in the go.mod files are correct now, while others still get an invalid pseudo version, despite having deleted the cached modules.

I guess a replace could work (as in so many cases where people reported problems with submodules or invalid pseudo versions), but I just wanted to point out that deleting the module cache doesn't seem to solve the issue in all cases.

If this is unexpected behavior I can provide more details. If this is expected behavior then maybe a clarification helps me and future GitHub issue readers to understand it better.

go version go1.12.7 windows/amd64