search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.16k stars 17.69k forks source link

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

Open mitar opened 6 months ago

mitar commented 6 months ago

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:

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 commented 6 months ago

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 commented 6 months ago

CC @matloob

fgm commented 6 months ago

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 commented 6 months ago

cc @samthanawalla

This seems like it could be useful.

mitar commented 6 months ago

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

seankhliao commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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

Would that be enough for people?

rsc commented 5 months ago

Have all remaining concerns about this proposal been addressed?

The proposal details are in https://github.com/golang/go/issues/67420#issuecomment-2150584249.

mitar commented 5 months ago

I think so. Thanks.

gaby commented 5 months ago

Yes, they do.

jimmyfrasche commented 5 months ago

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

rsc commented 5 months ago

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

rsc commented 4 months ago

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

The proposal details are in https://github.com/golang/go/issues/67420#issuecomment-2150584249.

rsc commented 4 months ago

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 https://github.com/golang/go/issues/67420#issuecomment-2150584249.

icholy commented 3 weeks ago

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