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
Labels
Documentation FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@rogpeppe
Copy link
Contributor

$ 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
Copy link
Member

myitcv commented Jul 17, 2019

cc @bcmills @jayconrod

@myitcv myitcv added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 17, 2019
@myitcv myitcv added this to the Go1.13 milestone Jul 17, 2019
@myitcv
Copy link
Member

myitcv commented Jul 17, 2019

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

@bcmills
Copy link
Contributor

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
@bcmills bcmills added Documentation NeedsFix The path to resolution is known, but the work has not been done. labels Jul 17, 2019
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 17, 2019
@myitcv
Copy link
Member

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

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

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

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

@golang golang locked and limited conversation to collaborators Jul 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants