Ask questionscmd/go: major version without preceding tag must be v0, not v1 - breaks build of

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version

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

Does this issue reproduce with the latest release?


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

<details><summary><code>go env</code> Output</summary><br><pre> $ 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=",direct" GOROOT="/home/travis/.gimme/versions/go" GOSUMDB="" 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/" 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" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on is best. -->

I am running my tests against go:tip in Travis. This is breaking build for external library.

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: requires requires invalid pseudo-version: major version without preceding tag must be v0, not v1


Answer questions 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 v1.0.0-20180628173108-788fd7840127


require 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 v1.0.0-20180628173108-788fd7840127 => 788fd7840127

then run go mod tidy.


Related questions

cmd/link: segmentation fault during mach-o linking hot 6
cmd/vet: potential false positive in the "suspect or" check hot 3
cmd/go: cannot find module providing package error stops `go get` processing hot 3
vendor/ undefined: errors.Frame ... hot 2
cmd/cgo error: runtime: unknown pc 0x7fff5c805b86 hot 2
internal/poll: transparently support new linux io_uring interface hot 2
Plis fixit! Its not good!!! hot 2
cmd/go: needs a better error than "missing dot in first path element" when GOROOT is set incorrectly hot 2
x/mobile: gomobile bind is failing with latest version [+cafc553] of gomobile hot 2
cmd/go: "found, but does not contain package" error refers to replaced version instead of its replacement hot 2
x/xerrors: fails to compile on tip hot 1
cmd/go: `go clean <package>` downloads modules hot 1
runtime: crash with "invalid pc-encoded table" hot 1
cmd/link: showing many ld warnings of "building for macOS, but linking in object file" hot 1
runtime: go program crach, it seems fall into infinite loop hot 1
Github User Rank List