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.

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 A@v1.0.0 to A@v2.0.0 shouldn't happen.

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?

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.