cmd/go: go get -u should not upgrade to unstable version

[andig]

What version of Go are you using (go version)?

$ go version
go version go1.18 darwin/arm64

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
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.18/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.18/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build723949441=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.18 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.18
uname -v: Darwin Kernel Version 21.4.0: Mon Feb 21 20:36:53 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	12.3
BuildVersion:	21E230
lldb --version: lldb-1316.0.9.41
Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

What did you do?

go get -u

What did you expect to see?

Stable versions updated to stable versions only.

What did you see instead?

go: downloading github.com/influxdata/influxdb-client-go/v2 v2.8.1
go: downloading golang.org/x/crypto v0.0.0-20220321153916-2c7772ba3064
go: downloading github.com/AlecAivazis/survey/v2 v2.3.4
go: downloading github.com/muka/go-bluetooth v0.0.0-20220323170840-382ca1d29f29
go: downloading golang.org/x/sys v0.0.0-20220319134239-a9b59b0215f8
go: downloading google.golang.org/protobuf v1.28.0
go: downloading github.com/aws/aws-sdk-go v1.43.24
go: downloading google.golang.org/genproto v0.0.0-20220324131243-acbaeb5b85eb
go: downloading github.com/Netflix/go-expect v0.0.0-20220104043353-73e0943537d2
go: downloading github.com/hinshun/vt10x v0.0.0-20220119200601-820417d04eec
go: downloading github.com/kr/pty v1.1.1
go: upgraded github.com/AlecAivazis/survey/v2 v2.3.2 => v2.3.4
go: upgraded github.com/aws/aws-sdk-go v1.42.35 => v1.43.24
go: upgraded github.com/deepmap/oapi-codegen v1.9.0 => v1.9.1
go: upgraded github.com/godbus/dbus/v5 v5.0.6 => v5.1.0
go: upgraded github.com/googleapis/gax-go/v2 v2.1.1 => v2.2.0
go: upgraded github.com/gorilla/websocket v1.4.2 => v1.5.0
go: upgraded github.com/grid-x/modbus v0.0.0-20220110162222-619e2e635c62 => v0.0.0-20220210093200-c7b3bba92b40
go: upgraded github.com/influxdata/influxdb-client-go/v2 v2.6.0 => v2.8.1
go: upgraded github.com/itchyny/gojq v0.12.6 => v0.12.7
go: upgraded github.com/jinzhu/copier v0.3.4 => v0.3.5
go: upgraded github.com/klauspost/compress v1.14.1 => v1.15.1
go: upgraded github.com/magiconair/properties v1.8.5 => v1.8.6
go: upgraded github.com/miekg/dns v1.1.45 => v1.1.47
go: upgraded github.com/muka/go-bluetooth v0.0.0-20220219050759-674a63b8741a => v0.0.0-20220323170840-382ca1d29f29
go: upgraded github.com/nicksnyder/go-i18n/v2 v2.1.2 => v2.2.0
go: upgraded github.com/onsi/gomega v1.17.0 => v1.18.1
go: upgraded github.com/prometheus/client_golang v1.11.0 => v1.12.1
go: upgraded github.com/spf13/afero v1.8.1 => v1.8.2
go: upgraded github.com/spf13/cobra v1.3.0 => v1.4.0
go: upgraded github.com/thoas/go-funk v0.9.1 => v0.9.2
go: upgraded golang.org/x/crypto v0.0.0-20220214200702-86341886e292 => v0.0.0-20220321153916-2c7772ba3064

--> this is unexpected

go: upgraded golang.org/x/mod v0.5.1 => v0.6.0-dev.0.20220106191415-9b9b3d81d5e3

go: upgraded golang.org/x/sys v0.0.0-20220310020820-b874c991c1a5 => v0.0.0-20220319134239-a9b59b0215f8
go: upgraded golang.org/x/tools v0.1.8 => v0.1.10
go: upgraded google.golang.org/genproto v0.0.0-20220310185008-1973136f34c6 => v0.0.0-20220324131243-acbaeb5b85eb
go: upgraded google.golang.org/protobuf v1.27.1 => v1.28.0
go: upgraded gopkg.in/ini.v1 v1.66.3 => v1.66.4

[mknyszek]

Is this new in Go 1.18?

CC @bcmills

[mknyszek]

Oops, meant to also CC @matloob.

[seankhliao]

x/tools has required x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3
this is working as expected for mvs

[NHDaly]

I had the same expectation as @andig.

The documentation here describes that for early modules, we should use a leading v0 to indicate an "unstable version":
https://go.dev/blog/publishing-go-modules

v0: the initial, unstable version

Let’s tag the module with a v0 semantic version. A v0 version does not make any stability guarantees, so nearly all projects should start with v0 as they refine their public API.

[...]

Now other projects can depend on v0.1.0 of example.com/hello. For your own module, you can run go list -m example.com/hello@v0.1.0 to confirm the latest version is available (this example module does not exist, so no versions are available). If you don’t see the latest version immediately and you’re using the Go module proxy (the default since Go 1.13), try again in a few minutes to give the proxy time to load the new version.

If you add to the public API, make a breaking change to a v0 module, or upgrade the minor or version of one of your dependencies, increment the MINOR version for your next release. For example, the next release after v0.1.0 would be v0.2.0.

This document encourages developers to indicate breaking changes by updating the MINOR version number for these "unstable version" modules.

While, yes, the documentation for -u currently indicates that it updates all packages to newer minor or patch releases, so it is currently performing correctly according to the documentation 👍

The -u flag instructs get to update modules providing dependencies
of packages named on the command line to use newer minor or patch
releases when available.

However, this does not support the spirit of the "v0 initial, unstable version" which is encouraged from the documentation.

So currently, there is no way for developers to achieve both of these aims:

1. indicate that a module is still pre-release, and not yet ready for general consumption
2. release an update containing a breaking change, without breaking all clients.

[Julio-Guerra]

@seankhliao, could you reopen this issue since the problem is about go get not considering v0 versions as unstable and we are therefore experiencing random compilation issues when go get -u is performed and that a breaking change has been introduced into some v0 module. This makes go get -u unsafe to use.