cmd/go: add release notes for @upgrade and @latest

[rogpeppe]

$ go version
go version devel +a05c132064 Wed Jul 10 15:52:04 2019 +0000 linux/amd64

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rog/.cache/go-build"
GOENV="/home/rog/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="github.com/heetch"
GONOSUMDB="github.com/heetch"
GOOS="linux"
GOPATH="/home/rog/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/rog/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/rog/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/rog/src/heetch/galaxy-go/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-build944198813=/tmp/go-build -gno-record-gcc-switches"

The following testscript script demonstrates the issue. I would expect go get $m and go get $m@latest to be synonyms, but they aren't.

# note: the latest tagged version of gommon when this issue was created
# was v0.2.9.

# Go get should update the version of the module to the latest
# published version (v0.2.9) but that doesn't happen. Instead,
# nothing changes.
cp go.mod-orig go.mod
go get github.com/labstack/gommon
cp go.mod go.mod-1

# Go get with an explicit `@latest` does work as expected.
cp go.mod-orig go.mod
go get github.com/labstack/gommon@latest
cp go.mod go.mod-2

# The two resulting go.mod files should be identical, but are not.
cmp go.mod-1 go.mod-2
-- go.mod-orig --
module example.com/m

go 1.13

require (
	github.com/labstack/gommon v0.2.10-0.20190711173550-1f43c1e9c3eb
)
-- main.go --
package main
import _ "github.com/labstack/gommon"

func main() {
}

[myitcv]

cc @bcmills @jayconrod

[myitcv]

Tentatively marking as a release blocked, because this appears to be a regression compared to go1.12.7

[bcmills]

Argh, looks like we forgot to update the release notes for #32846.

[myitcv]

The docs at tip read as follows:

For each named package or package pattern, get must decide which version of
the corresponding module to use. By default, get chooses the latest tagged
release version, such as v0.4.5 or v1.2.3. If there are no tagged release
versions, get chooses the latest tagged pre-release version, such as
v0.0.1-pre1. If there are no tagged versions at all, get chooses the latest
known commit.

That suggests to me that go get $m (without any @ business) should downgrade, no?

[jayconrod]

I'll update the documentation today.

The default is the new @upgrade suffix, which will be new in 1.13. @upgrade is like @latest but if you're already on a newer version than @latest would pick (i.e., a pre-release or pseudo-version), it will not downgrade you. An explicit @latest has the same behavior as it did before: it will ignore the current version, so you may downgrade if you're on a newer version.

[myitcv]

Thanks for clarifying. Yeh, just a tweak in the docs and calling out this specific point in the change for go get $m in the release notes will help people me with hangovers from the good old days 😄

[gopherbot]

Change https://golang.org/cl/186618 mentions this issue: cmd/go: document go get @upgrade behavior in release notes