The go list -m -u command (and also go get with no explicit version) does not always suggest an upgrade to the latest available version number. In this case, the commit date for email@example.com is earlier than the commit date for the current pseudo-version, but it's not clear from the documentation, which says:
When the latest version of a given module is newer than
the current one, list -u sets the Module's Update field
to information about the newer module.
whether "newer" means "later version number" (in which case I'd expect it to suggest v1.2.0) or "latest commit date" (in which case the suggestion is right). If it really is "latest commit date", then I'd be concerned about backports - a backport of a fix from a later version could then prevent automatic upgrades to the appropriate latest version.
I think this could at least use some clarification in the docs.
This is working as intended, but the documentation for go list and go get doesn't explain well enough what's happening. That should be improved in the module reference documentation at least (#33637).
go list -m -u, go get with no specific version specified, and go get -u all use the @upgrade version query. @upgrade is like @latest, but if the current version is semantically higher than the version matched by @latest (for example, a newer pre-release), or if the current version is a pseudo-version with a chronologically later commit date, then @upgrade matches the current version instead of the @latest version.
That should be improved in the module reference documentation at least
Yes, I'm now sure that this is doing the right thing, but it was confusing to me even after I'd read through the docs. Rather than closing it, I'll retitle this issue to something a bit more specific than #33637 because ISTM that this particular aspect of the docs might easily fall between the cracks again.
changed the title
cmd/go: go list -u -m does not always print available upgradesJun 15, 2020