Mozilla.Firefox 128.0 version mismatch

[olegpro81]

Please confirm these before moving forward

• [X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• [X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Other

Brief description of your issue

Hi team,

Firefox online and local versions don't match.

Steps to reproduce

.\winget.exe list -e --id Mozilla.Firefox --scope machine and .\winget.exe search -e --id Mozilla.Firefox --accept-source-agreements

Actual behavior

Looks like when after installing Firefox 128 and running a local version search it will show as 128.0. But when searching online version will be 128. This is breaking all the install/uninstall scripts as well as detection and remediation. Local search: Name Id Version Source

Mozilla Firefox (x64 en-US) Mozilla.Firefox 128.0 winget

Online search:

Name Id Version Source

Mozilla Firefox Mozilla.Firefox 128 winget

Expected behavior

Same version would be desirable, as we need to fix the scripts every time new version is released.

Environment

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

Windows: Windows.Desktop v10.0.22621.3880
System Architecture: X64

Winget Directories                 
------------------------------------------------------------------------------------------------------
Logs                               %TEMP%\WinGet\defaultState
User Settings                      %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json
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
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Screenshots and Logs

[stephengillie]

The latest PR has PackageVersion: "128.0", where the quotes should ensure that the version is interpreted as a string. I'm not sure that this is a manifest issue, and might instead be a package manager issue.

[Trenly]

I don’t think this is a bug necessarily, since the version parsing in WinGet treats 128, 128.0, and 128.0.0.0.0.0.0.0 all as the same version. If you run winget upgrade you should see that there is no upgrade available.

I do agree that it is confusing that the trailing zero is trimmed off, especially when it isn’t trimmed for winget search mozilla.vpn

[Trenly]

I checked with 1.9.1763-preview and saw the issue, downgraded to 1.8.1911 and still saw the issue, downgraded again to 1.7.11261 which required me to remove the AppxPackage for Microsoft.Winget.Source and the issue went away.

I then upgraded to 1.8.1133-preview and the issue remained resolved, so I upgraded to 1.8.1911 again and the issue remained resolved, so I upgraded to 1.9.1792-preview and the issue remained resolved. So, I tried winget source update and the issue came back.

I think this points to IndexV2 as being the culprit here - perhaps @johnmcpms has some insights into why the trailing .0's are being trimmed for some (but not all) versions in winget search on IndexV2. It seems they are only trimmed for versions which have 2 parts?

@stephengillie /@denelon - I believe that also means this issue should be transferred to winget-cli

[JohnMcPMS]

I definitely touched code that deals with versions when searching with v2, so I think it does make sense to transfer the issue. I'm not really following what the problem or the desired behavior is though. Is this breaking a script that is processing the output and does not like the difference between "128" and "128.0"? If that is the case, is the desired result simply that they match, regardless of whether they include the extraneous ".0" or not?

[Trenly]

I'm not really following what the problem or the desired behavior is though. Is this breaking a script that is processing the output and does not like the difference between "128" and "128.0"? If that is the case, is the desired result simply that they match, regardless of whether they include the extraneous ".0" or not?

That is my understanding. From the initial post, it seems like there are scripts users have built which compare the output of winget list <package> to the output of winget search <package>. It sounds like the script is expecting the versions to match and is performing some action if they do not (could be argued the script is improperly written to compare them as strings instead of casting them to versions, but we'll ignore that for now).

The ask, then, would be - when using winget search and IndexV2 the trailing ".0" is not trimmed from versions

[olegpro81]

Ok never mind, I will update my scripts to cover this kind of changes. Thanks.