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: add release notes for @upgrade and @latest #33149

Closed
rogpeppe opened this issue Jul 17, 2019 · 7 comments
Closed

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

rogpeppe opened this issue Jul 17, 2019 · 7 comments

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Jul 17, 2019

$ 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() {
}
@rogpeppe rogpeppe added the modules label Jul 17, 2019
@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jul 17, 2019

@myitcv myitcv added this to the Go1.13 milestone Jul 17, 2019
@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jul 17, 2019

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

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jul 17, 2019

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

@bcmills bcmills changed the title cmd/go: go get doesn't always update to latest cmd/go: add release notes for @upgrade and @latest Jul 17, 2019
@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jul 17, 2019

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 jayconrod self-assigned this Jul 17, 2019
@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Jul 17, 2019

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

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Jul 17, 2019

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jul 17, 2019

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

@gopherbot gopherbot closed this in f518a96 Jul 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.