The exclude directive in the go.mod file gets us partway there: if there is some regression, such as a large set of new dependencies or a significant performance degradation, then either the maintainers should fix that regression and issue a new release, or the users should fork the module to remove the unwanted bloat. Either way, the need to hold back should only persist for a release or two.

It may be that we should resolve the cyclic dependency problem in some other way, such as having go get -u detect the cycle and try to upgrade past it (#27899). In particular, we can't stop outside users of a given module from introducing newer requirements, so it seems fragile to rely on the version staying at some older release.

Finally, if there is a breaking change in a v0 version, then perhaps it's best to have a reminder to fix the call site. (As a workaround, you can always pass an explicit older version of a particular module to go get -u, and having that explicit in the update command is a good indicator of the Damocles' Sword of Incompatibility that is looming over your module...)

I don't have a good sense of the severity or frequency of these issues. As you point out, there are alternatives for all of them, but I'm not sure how often they're going to come up or how annoying they're going to be.

Let's mark this as Unplanned and decide what to do after modules are on by default. I don't think this is a critical feature to have before then.

I think the best fit for this use-case is a special version query. upgrade already means “current selected version or higher”, and patch means “current selected version or higher but within the same minor version”; the logical progression of those is some third token (maybe current?) meaning “current selected version and no higher”.

What are the chances that this might ever happen in some capacity? I'm in a scenario right now where I want to update all the dependencies in my go.mod except for one due to a breaking change that we are not yet ready to adopt. Effectively, I'd like to pin this dependency to the version we have now while still allowing everything else to update. I cannot find a way to properly accomplish that today.

@braydonk, today you can pass the version of the package or module that you want to keep to go get -u as an explicit argument, like:

go get -u ./... example.com/stuck@v0.5

Ah cool, I wasn't able to find that anywhere when I was looking around documentation or even blog posts. Thank you for the trick!

I'd love to see this capability as well. On one codebase I'm working, we have 3 particular dependencies which introduce breaking changes, so cannot be updated. I'd love the option to do something like go get -pin example.com/foo@v0.5, which I magine might add a // pinned comment after the relevant line in go.mod, so that subsequent go get -u ./... executions just skip the pinned modules.