Add package exclude list for 'winget upgrade --all'

[deadlydog]

Description of the new feature / enhancement

Sometimes you have a lot of packages to be upgraded, and updating them one at a time is very time consuming and cumbersome. You can use the winget upgrade --all feature, but there may be a few specific packages that you don't want updated. For example, there may be packages that you don't want to update for technical reasons (e.g. breaking changes in Ruby v2 to v3), or for other reasons, like your organization requires you to stay on a specific version of MS Office. Ideally, you could define a list of package IDs in the settings json file that winget upgrade --all would ignore.

Proposed technical implementation details

Add a new element to the settings.json schema that allows an array of package IDs to be specified which the upgrade --all flag excludes from upgrading. If there is an update available for a package defined in the exclude list, the upgrade --all command displays an information message that there is an update available for the package, but that it won't be installed because it is specified in the exclude list.

[jedieaston]

Duplicate of #1439 (hopefully that's coming soon).

[deadlydog]

Thanks @jedieaston. I read over #1439 and this issue is definitely similar, but slightly different. I think that issue is mainly wanting a way to ignore all updates to a given package, to be used when winget upgrade <package> does not do the correct thing (due to the package not having correct metadata, or other things like that).

In this issue, I would still want to be able to update a given package using winget upgrade <package>; I just want it ignored when using winget upgrade --all. So I would still be able to update the package using winget when I explicitly specify the package.

So there are two different use cases:

1. winget upgrade does not do the correct thing (for whatever reason).
2. winget upgrade would do the correct thing, but the user simply wants explicit control over when that package gets upgraded.

Perhaps the same solution could be used to solve both problems (e.g. there's a single exclude list, but it can be overridden with winget upgrade <package> --ignore-exclude-list), but I think it's important to call out both use cases to ensure one is not overlooked.

[jedieaston]

Agreed. I think a flag to override your pins/exclusions would be preferable.

[denelon]

Duplicate of #476

[ghost]

@deadlydog we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.

[exoosh]

Isn't the real underlying issue that winget crams all of the different ideas of "upgrade" into a single subcommand?

Thinking in terms of apt, you have upgrade but also dist-upgrade with different semantics. Pinning (#476) would at least be a stopgap solution.

I have the issue right now with VMware Workstation:

VMware Workstation                                        VMware.WorkstationPro               16.2.5           17.0.0       winget

Version 16.2.5 was released after 17.0.0 and using 17.0.0 requires a "renewal" of the license key which I don't want to rush at this point. So I can no longer use winget upgrade --all, because it would nuke my VMware Workstation Pro 16.x installation and upgrade it to 17.