dmitshur
commented
1 year ago Thanks for reporting this. CC @bcmills, @matloob.
I wanted to clarify a part of the "What did you do?" section. Specifically, when you start out with a go.mod file with support for Go 1.17 through 1.20 and a go 1.18 directive, how does it end up with go 1.21?
I tried to reproduce it as follows (using go1.21.0):
$ cd $(mktemp -d)
$ cat <<EOF >go.mod
module github.com/my/lib
go 1.18
require github.com/google/uuid v1.2.0
EOF
$ cat <<EOF >p.go
package p
import _ "github.com/google/uuid"
EOFAt that point, doing go get -u -v updated the uuid to its latest version v1.3.1, but left the go directive at its starting 1.18 value:
$ go get -u -v
go: trying upgrade to github.com/google/uuid@v1.3.1
go: upgraded github.com/google/uuid v1.2.0 => v1.3.1
$ cat go.mod
module github.com/my/lib
go 1.18
require github.com/google/uuid v1.3.1Similarly, running go mod tidy did clean up unused entries from go.sum, but otherwise left go.mod as it was before, with go 1.18:
$ go mod tidy
$ echo $?
0
$ cat go.mod
module m
go 1.18
require github.com/google/uuid v1.3.1Can you clarify what the reproduction steps are missing that's causing the problem? Thanks.
gaby
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
This is a continuation of https://github.com/golang/go/issues/57001
Lets say, I have a library made with Go that supports go version
1.17,1.18,1.19, and1.20.My go.mod file looks as follow:
Normally when getting updates, you would do
go get -u -vthengo mod tidy. Since go1.21 runninggo mod tidynow changes your go.mod file to the following:This a breaking change behavior, given that now if I commit that code? Any previous CI/CD process, or any other developer in the team that's using a different version of
gocan no longer build/test/run the code because of thetoolchaindirective.What did you expect to see?
I expected that running
go mod tidywould only cleanup imports and thego.sumfile.What did you see instead?
Running
go mod tidychanges thego.modgo version and adds a toolchain directive that's not available in any previous go version.Suggested solution
There's two possible solutions here:
gocommands use thelocalinstall by default instead ofauto.go mod tidycommand shouldn't change the version/add a directive togo.modExample running with
go 1.20.7in Docker:This bring the question, how can we write libraries that are backward compatible with previous go versions?