winget-cli add alternative version number field to manifest to make correlation with entries in Add/Remove programs more reliable
Description of the new feature/enhancement
As reported here, the winget upgrade command may incorrectly detect updates to be available even when the latest version is installed in case the version number in Add/Remove programs does not match the package version in the manifest.
One solution to this problem could be the addition of an additional version field to the manifest where the version number is specified in the format that is expected in Add/Remove programs. When present, the winget upgrade routine would use this version number instead of the package version to determine if an update is available or not.
This suggestion is closely related to microsoft/winget-pkgs#13620.
2 Answer:
@chausner we have another issue in the client I think this is a duplicate of https://github.com/microsoft/winget-cli/issues/976.
Edit: I didn't read fully.
This is part of the work we're doing with the new schema. We have added a section for data specifically matching what is reported via Apps & Features.
Read next
- winget-cli dev builds for winget
- winget-cli install failure - Dependancy not found - Microsoft.UI.Xaml
- winget-cli installation Guide for LTSC (and Server OS)
- Factor out a library from winget-cli so that bindings in other languages can be written
- winget-cli suppress reboot on default
- winget-cli winget support for supported Windows Server, Azure Stack HCI editions
- winget-cli uninstall fails when two versions have the same name, and different ID.
- winget-cli powerShell ISE doesn't like WinGet