In the Go 1.13 cycle, we made a couple of changes to go get -u:

• We made get -u equivalent to applying @latest to dependencies recursively.
  • This was done to make the relationship between -u and @latest parallel to -u=patch and @patch.
• We made get -u not downgrade from versions newer than the latest tagged release (cmd/go: list -u -m and get -u suggest downgrades from pseudo-versions after latest #30634).

Those changes individually makes sense, but combined they produce a counter-intuitive result: an explicit go get foo@latest does not downgrade to the latest release, when it arguably should. That makes issues like #32805 more subtle to diagnose, because commands like go get golang.org/x/tools/gopls@latest are unexpectedly sensitive to the initial state.

I talked with @jayconrod and @rsc about this result, and we have a consensus about what to do about it. The current plan (for Go 1.13!) is:

• Add an @upgrade suffix, with the meaning “@latest, but only if newer than the active version”.
• Make -u without arguments apply @upgrade (instead of @latest) to the named arguments and their dependencies.
• Reject -u=latest (as it was in Go 1.12), so that the supported arguments to -u are only those whose behavior depends on the active version.
  • But continue to support @latest as an explicit suffix, with its meaning from Go 1.12 (always the latest release version, even if that is a downgrade from the currently active version).
• For arguments passed to go get without an explicit suffix:
  • Retain the current (go1.13beta1) behavior of -u=patch, which implicitly adds the @patch suffix.
  • Retain the current (go1.13beta1) behavior when -u is unset, which upgrades (but does not downgrade) only the named arguments.
    • This behavior will now corresponds to the @upgrade suffix instead of @latest.

@jayconrod has volunteered to implement this fix.

CC @thepudds @myitcv @leitzler @hyangah