Open olegpro81 opened 3 months ago
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.
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
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
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?
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
Ok never mind, I will update my scripts to cover this kind of changes. Thanks.
Please confirm these before moving forward
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
Screenshots and Logs