Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
myitcv opened this issue Nov 27, 2018 · 6 comments
Closed
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@myitcv
Copy link
Member

myitcv commented Nov 27, 2018

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

@myitcv myitcv added this to the Go1.12 milestone Nov 27, 2018
@bcmills
Copy link
Contributor

bcmills commented Nov 27, 2018

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 bcmills added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed release-blocker labels Nov 27, 2018
@bcmills bcmills assigned bcmills and ianlancetaylor and unassigned bcmills Nov 27, 2018
@bcmills
Copy link
Contributor

bcmills commented Nov 27, 2018

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

@bcmills bcmills modified the milestones: Go1.12, Go1.11.3 Nov 27, 2018
@myitcv
Copy link
Member Author

myitcv commented Nov 27, 2018

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
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 27, 2018
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 27, 2018
@bcmills
Copy link
Contributor

bcmills commented Dec 6, 2018

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.

@bcmills bcmills closed this as completed Dec 6, 2018
@rogpeppe
Copy link
Contributor

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

@dmitshur dmitshur modified the milestones: Go1.11.3, Go1.11.4 Dec 13, 2018
@FiloSottile FiloSottile added the CherryPickApproved Used during the release process for point releases label Dec 14, 2018
@golang golang locked and limited conversation to collaborators Dec 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

7 participants