Nonsensical version tracking and listing

[TheGhostOfInky]

Brief description of your issue

On the below screenshot you can see Winget suggesting 4 updates for packages that are all on the latest version:

Firefox Developer edition:

The version actually installed is 119.0 Beta 5, the latest available for that release channel, but Winget detects a non-beta release of 119.0 (which will never exist since developer edition only gets beta channel builds) and suggests me "upgrade" to the previous beta.

This is problematic for 2 reasons:

1. Winget should be aware of which packages list the beta build on their version info or not, and avoid recommending beta build updates to those who do not.
2. According to semantic versioning 119.0 is a more updated release than 119.0b4, so even if I was theoretically running 119.0 release, it would be newer than beta 4 and therefore Winget is suggesting me a downgrade.

Microsoft Windows Desktop Runtime - 3.1.32

Winget is suggesting me to replace the 3.x desktop runtime with a completely incompatible version of the .NET desktop runtime (which for the record I have installed as well).

This is a serious issue as it would cause an update loop, as the 3.1.32 runtime is not overwritten by the 6.0.22 one and therefore will still show an update available after the install of the "updated" package.

Epic Games Launcher

This program is on the latest version according to the launcher's internal updater (15.15.0-2846563), neither the version Winget claims the program currently is or the one Winget claims is the latest can be found anywhere in the program, including the executable's version details.

Ideally Winget would not touch programs like these that include their own installers, but unfortunately the closest we have to a package ignore list is pinning, which breaks the program's internal updaters.

Python 3.12.0

Perhaps the most puzzling of them all, Winget detects my Python 3.12 install as an unknown version Python 3.11 install and is trying to get me to update to the version it currently is at. This is an issue for 2 reasons:

1. Why is it detecting Python 3.12.0 as a version of Python 3.11 when they are different packages on Winget?
2. If it thinks it's Python 3.11.x why is trying to upgrade to Python 3.12, a non-directly compatible release?

All of these are recurring issues that manifest themselves frequently and cause me to have to avoid the convenient winget upgrade --all command.

Steps to reproduce

Install the aforementioned packages and run winget upgrade

Expected behavior

Only packages with newer versions available would show updates.

Actual behavior

Inexistent updates show as available.

Environment

Windows Package Manager v1.6.2771
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.2361
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

[denelon]

Some of this is related to:

• Matching logic needs to be updated. #2995

Python is split out in the repository as separate packages, but the matching logic still detects the newer versions due to the metadata written by the installer. One possible workaround for this package is to pin it to the version or "range" of versions you want.

When you see a ">" or a "<" in a version, it's an indication that the manifest is using a "marketing version" (packageVersion) rather than what the installer actually writes to the registry (Apps & Features displayVersion). Often the reason is due to the installed "displayVersion" not having a corresponding manifest in the community repository.

[BrandonWanHuanSheng]

Looking to Python.Python to see if there is 0 file..

[BrandonWanHuanSheng]

Yes, 0 file was existed.

Highly recommend use AppsandFeaturesEntries:
The possible data is here.
python.python.3.12 version 3.12.0 x64


python.python.3.12 version 3.12.0 x86

[BrandonWanHuanSheng]

Action before Id column which is Upgrade Code.
Id15 could be the ProductCode for the setup.