cmd/go: list deprecations and newer available major, minor versions

[mitar]

Proposal Details

This is a followup to #40323. In there the proposal was to print out warnings during other commands when there are newer versions of modules available.

This proposal instead proposes a new sub-command to go mod, something like go mod check or go mod upgradeable which would check existing dependencies for:

• Deprecations.
• Available minor versions.
• Available major versions.

It could print that out in readable format or in JSON format (so that other tools could take that as input). I think this would allow then various plumbing with CI and other tooling to get warnings, errors, notifications, e-mail notifications, whatever. It would also not pollute all other go commands with messages people might not expect. I can imagine then somebody making a linter for golangci-lint which would require that everything is on the latest version. Or whichever policy you want.

The command could then also be extended in the future (suggesting fixes, adding additional checks - like suggesting which version changes might reduce the number of different versions in the program) without adding noise to existing other commands.

[H0llyW00dzZ]

Proposal Details

This is a followup to #40323. In there the proposal was to print out warnings during other commands when there are newer versions of modules available.

This proposal instead proposes a new sub-command to go mod, something like go mod check or go mod upgradeable which would check existing dependencies for:

• Deprecations.
• Available minor versions.
• Available major versions.

It could print that out in readable format or in JSON format (so that other tools could take that as input). I think this would allow then various plumbing with CI and other tooling to get warnings, errors, notifications, e-mail notifications, whatever. It would also not pollute all other go commands with messages people might not expect. I can imagine then somebody making a linter for golangci-lint which would require that everything is on the latest version. Or whichever policy you want.

The command could then also be extended in the future (suggesting fixes, adding additional checks - like suggesting which version changes might reduce the number of different versions in the program) without adding noise to existing other commands.

That would be useful instead of currently having to manually click Check for upgrades | Upgrade transitive dependencies | Upgrade direct dependencies in the IDE.

[ianlancetaylor]

CC @matloob

[fgm]

Maybe that command could provide more info than just versions, to avoid having to introduce multiple such go mod subcommands over time. Consider for example composer show <package> --all providing all metadata about a package.

Otherwise, we have prior art like composer outdated, yarn outdated, npm outdated. And there is a similar discussion in the Rust community at rust-lang/cargo#4309 (comment) (open since 2017), which includes a nice summary of equivalent features in other languages as prior art.

[matloob]

cc @samthanawalla

This seems like it could be useful.

[mitar]

@seankhliao You changed the title, but my proposal is for both major and minor versions.

[seankhliao]

I did, but minor version info is already available (the -u and -versions flag for go list). What's new and hard is obtaining information about major versions.

[mitar]

Hm, I was hoping for one command to show me all version information. But yes, adding major is new and hard, but I still think it is useful to have one command which can show both. One reason is that you can sometimes then see that a module has both a newer minor and newer major version, implying that the old major version is still maintained.

[jimmyfrasche]

Having a single clear place to go to get all version related questions answered is good UX. I don't want to have to remember two things. That's one too many things!

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

What if we add a new MajorUpdate field to the Module struct that is output from go list -m, with these semantics:

• go list -m -u # sets Deprecated, Update (latest minor) (this already exists)
• go list -m -u=patch # sets Deprecated, Update (latest patch; this would be new)
• go list -m -u=major # sets Deprecated, Update (latest minor), MajorUpdate (this adds MajorUpdate)

Would that be enough for people?

[rsc]

Have all remaining concerns about this proposal been addressed?

The proposal details are in #67420 (comment).

[mitar]

I think so. Thanks.

[gaby]

Yes, they do.

[jimmyfrasche]

Would -u=major also contain the results for -u=patch and just -u; or would it only show major updates?

[rsc]

No, each -u contains one result, since the (pre-existing) Update field can only describe one version.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

The proposal details are in #67420 (comment).

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The proposal details are in #67420 (comment).

[icholy]

Does this proposal include a corresponding change to the module proxy? Perhaps a prefix filter for index.golang.org?

GET https://index.golang.org/index?prefix=github%2Ecom%2Ffoo%2Fbar