Pipeline says package was published, but source is not updated

[fnando]

Hi! According to https://github.com/microsoft/winget-pkgs/blob/master/doc/FAQ.md#how-long-do-packages-take-to-be-published, packages are published every hour or so.

A package I submitted last Tuesday has a "Published Pipeline: Healthy" label, but I can't seem to find the latest version.

PS C:\Users\fnando\Projects> date

Thursday, November 21, 2024 1:38:51 PM

PS C:\Users\fnando\Projects> winget source update && winget search --id Stellar.StellarCLI
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Done
Name        Id                 Version     Source
--------------------------------------------------
Stellar CLI Stellar.StellarCLI 22.0.0-rc.1 winget

PS C:\Users\fnando\Projects> winget upgrade --id Stellar.StellarCLI
No available upgrade found.
No newer package versions are available from the configured sources.

Is the package really available or is that some aggressive caching on Windows side? Is there a way I can forcefully update the cache by removing some files?

Cheers!

[mdanish-kh]

The problem isn't with publishing, the version was published successfully which you can check with

 ~ winget show Stellar.StellarCLI --versions
Found Stellar CLI [Stellar.StellarCLI]
Version
-----------
22.0.0-rc.1
22.0.0

Why you're not seeing an available upgrade is because WinGet version sorting logic ranks 22.0.0-rc.1 higher than 22.0.0. Until WinGet has better support for release channels ( tracked in issue microsoft/winget-cli#147 ), I would suggest not publishing release candidate builds.

[Trenly]

For my own reference when I get time to dive into where the issue is, here is the code that compares the two versions -

• https://github.com/microsoft/winget-cli/blob/25ccc2a6db72b88daab6447668f1437eb61649ad/src/AppInstallerSharedLib/Versions.cpp#L140-L171

In this case, it should be hitting the path that the parts are not equal, so that would be in the part comparator -

• https://github.com/microsoft/winget-cli/blob/25ccc2a6db72b88daab6447668f1437eb61649ad/src/AppInstallerSharedLib/Versions.cpp#L324-L352

[Trenly]

I did confirm that this seems to be a bug in the client by adding a new test, which caused it to fail -

E:\winget-cli\src\AppInstallerCLITests\Versions.cpp(122): FAILED:
  REQUIRE( vA < vB )
with expansion:
  {?} < {?}

===============================================================================
test cases:  1 |  0 passed | 1 failed
assertions: 71 | 70 passed | 1 failed

[Trenly]

Oh my. This is a weird bug.

    RequireLessThan("1-rc", "1"); // Test case passes
    RequireLessThan("1.2-rc", "1.2"); // Test case passes
    RequireLessThan("1.0-rc", "1.0"); // Test case fails

Edit: I'm very confused now. When comparing the individual parts, the parts are compared just fine

    RequirePartLessThan("2-rc", "2"); // Test case passes
    RequirePartLessThan("0-rc", "0"); // Test case passes

[Trenly]

I'm just going to keep leaving myself notes here so that I don't forget. I just had a thought.

When a version is created, all trailing zeroes are trimmed off. This means that 22.0.0, when broken into parts, is actually stored as [22] and not as [22, 0, 0]. This means that it's hitting the condition where i >= other.m_parts.size() and is just breaking the for loop instead of actually trying to pad with zeroes when comparing

Edit: Confirmed by removing the trimming, which caused the sorting to be correct. This isn’t a real fix though. . .

[Trenly]

PR has been raised - microsoft/winget-cli#5001