cmd/go: need to backport relaxing of go.mod go verb constraints to 1.11 series

[myitcv]

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

go version go1.11.2 linux/amd64
go version devel +bb3b24bffc Mon Nov 26 05:08:44 2018 +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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/tmp.zzDR1I4tSd"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/tmp.eq9VZVtX74/hello/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-build257586328=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Go 1.12 attempts to build/test/whatever a module with a go verb specifying the next or higher >= 1.13. However, this is a hard failure for Go 1.11.

$ cd $(mktemp -d)
$ go version
go version devel +bb3b24bffc Mon Nov 26 05:08:44 2018 +0000 linux/amd64
$ cat <<EOD > go.mod
module example.com/blah
go 1.13
EOD
$ cat <<EOD > blah.go
package blah
EOD
$ go test
?       example.com/blah        [no test files]

# switch to Go 1.11.2

$ go version
go version go1.11.2 linux/amd64
$ go test
go build example.com/blah: module requires Go 1.13

What did you expect to see?

I think we will need a Go 1.11 release in order for modules created with Go 1.12 to be usable by those who don't immediately upgrade to 1.12.

What did you see instead?

Failures as above.

cc @rsc @bcmills @ianlancetaylor

[bcmills]

I don't think this is significant enough to be worth backporting. If the problem is that stuff tagged go 1.13 doesn't build on 1.11, maybe don't try to build it with 1.11? (Conversely, if it does build on 1.11, then tag it 1.11 instead of 1.13.)

Note that ~no code in the wild today should be tagged go 1.13 anyway, since it can only be tested against 1.13 with the use of a time machine. 😛

[bcmills]

Assigning to @ianlancetaylor for decision, since it's his patch we'd need to backport. (I'm leaning “no”.)

[myitcv]

The problem is that when you go mod init with tip it automatically adds go 1.12 to the go.mod. Which immediately means that anyone using Go1.12 will create modules that cannot be used by users of Go1.11 (unless we back port this fix)

[ianlancetaylor]

I think it makes sense to backport just the part of the patch that lets the build go through, and gives an appropriate warning if it fails. I'll send a CL for the 1.11 branch.

[bcmills]

I believe this is resolved by https://golang.org/cl/151358 (“[release-branch.go1.11] cmd/go: don't fail if requested Go version is later than current one”).

@ianlancetaylor, please reopen if I'm mistaken.

[rogpeppe]

This is an ongoing pain for me. Really hoping for go1.11.3 soon :)