cmd/go: go.mod can not lock indirect dependencies version

[bejens]

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

go1.14.7 windows/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\18511\AppData\Local\go-build
set GOENV=C:\Users\18511\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\18511\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\18511\AppData\Local\Temp\go-build311380846=/tmp/go-build -gno-record-gcc-switches

What did you do?

There are 3 go modules A: v1.0.0, B:v1.0.0, C:v1.0.0. Now it is known that B:v1.0.0 depends on A:v1.0.0, and C:v1.0.0 depends on B:v1.0.0. When B:v1.0.0 -> B:v2.0.0, A:v1.0.0 -> A:v2.0.0 (incompatible upgrade), use go get -u B to upgrade the version of B in the C project, B was upgraded to v2.0.0, and A was also upgraded to v2.0.0, causing the C project to fail to run.

What did you expect to see?

I hope lock the indirect dependency version

What did you see instead?

[dmitshur]

There isn't a way to enable locking indirect dependency versions in libraries in the general case, as that would cause problems elsewhere. It was considered during the design of the Minimal Version Selection algorithm (see https://research.swtch.com/vgo-mvs).

If you're not looking to update indirect dependencies, you probably should not use -u flag with go get.

Finally, in the example you shared, a jump from v1.0.0 to v2.0.0 is not expected to be backwards compatible per semantic version rules. Did you mean to use something like v1.0.0 to v1.1.0 instead?

I believe this is working as intended. If you think there is a specific problem, please elaborate.

/cc @bcmills @jayconrod @matloob per owners.

[jayconrod]

This does seem like it's working as intended. Requirements in go.mod files are minimum versions, not pinned versions. It should be safe to upgrade to any later version of the same module.

Note that higher major versions (v2.0.0 and above) technically belong to different modules. So if example.com/A is the original module, example.com/A/v2 is the v2 module. The go command can't upgrade across major versions, so the upgrade from [email protected] to [email protected] shouldn't happen.

[bejens]

At present, there are indeed many upgrade management solutions in github that do not use the standard go package. When using these packages, you often use go get -u to upgrade your own dependencies. However, the use of the -u parameter has been upgraded. Indirect dependency, which may cause the project to fail to start normally. Why does the version management of go not depend on the interval setting of the version?

[jayconrod]

Why does the version management of go not depend on the interval setting of the version?

Modules work differently than other dependency management systems, which are traditionally designed around constraint satisfaction algorithms. The module system is designed around minimal version selection, which is a fast, predictable algorithm at the cost of some flexibility. Modules must follow semantic versioning and must declare module paths matching their major versions. As long as those rules are followed, go get -u won't automatically upgrade to an incompatible version, since a new major version of a module (after v2) is treated as a distinct module by the algorithm.

You may find the vgo blog posts interesting, especially The Principles of Versioning in Go. They go into depth about the initial design of modules.

Closing this issue, because it doesn't sound like there's a specific bug to fix here.