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

[mitar]

Proposal Details

This is a followup to https://github.com/golang/go/issues/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 https://github.com/rust-lang/cargo/issues/4309#issuecomment-317505200 (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