Omit prerelease versions from update selection.

[4kbyte]

📖 Description

Prevent a prerelease version from being offered as an upgrade.

🔗 References

microsoft/winget-pkgs#368913

🔍 Validation

TDD: unit test.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[4kbyte]

@microsoft-github-policy-service agree

[Trenly]

This has the potential to be a breaking change for publishers who intentionally ship releases like this. Especially because there isn’t a switch that you've provided to bypass this behavior and haven’t updated any of the documentation to go with this change.

Your test case also doesn’t actually guarantee the sorting because 3.14.5 is always sorted as a higher version than 3.14.5rc1 regardless.

I understand the frustration that a release candidate slipping into stable packages causes, but I'm not sure that this check achieves the goal of preventing that in a meaningful way. Sure, it will stop some cases, but it breaks others and doesn’t capture the full spectum of behavior that WinGet has to account for.

Something like #147 would seem more along the lines of what is needed here, or an actual flag in the manifest indicating that a release is a pre-release.

• Support different release channels [released, beta, alpha] #147

Ultimately, though, this is a failure of the moderation in the source repository (winget-pkgs) and as a user of WinGet I'd rather see a proper fix there than a quick fix that has the potential to cause additional confusion when using the client.

[4kbyte]

Intent: Make stable releases the default upgrade target.

Correct that SemVer sorts 3.14.5 higher than 3.14.5rc1 (SemVer 2.0.0 section 11). That's why the patch is focused on GetLatestApplicableVersion and not SemVer handling. The test compares installed 3.14.4 against a single available manifest per case, not 3.14.5 against 3.14.5rc1; no sort is asserted.

This is larger than user experience; it's chain of trust. The winget project has become load-bearing for unattended upgrades. The original issue microsoft/winget-pkgs#368913 observes that Microsoft Store invokes winget.exe upgrade --scope user --accept-source-agreements --disable-interactivity daily.

A switch and docs are straightforward to add upon consensus. Complementary to #147, not a substitute.

[JohnMcPMS]

We can't make this change as the new default behavior without the potential for breaking something as @Trenly pointed out. It is not a security feature, it is a hurdle for a mistake to get tripped up on. Unfortunately it is susceptible to false positives in blocking.

If it were a setting that enabled this behavior, then --force could override it, that would be much easier to take without additional investigation.

[florelis]

Maybe we could run this on all the packages we currently have to know exactly what packages would be affected. If we know that it would not cause many issues, it may be easier to take the change. Although there would still be risk with other sources.

[JohnMcPMS]

Maybe we could run this on all the packages we currently have to know exactly what packages would be affected. If we know that it would not cause many issues, it may be easier to take the change. Although there would still be risk with other sources.

I had written that previously and replaced it with a "no" because there could be private sources with arbitrary version information out there that we do not know about. We cannot start blocking upgrades based on new rules without a lot more work than the code. Even if we all agree this is a reasonable thing and we can show it doesn't affect winget-pkgs at all (unless mistakes show up and it does its job), we would have to broadly communicate this breaking behavior change well in advance and include a policy setting that could disable it.

[Trenly]

I was also thinking that we could run it against all packages - but with over 12k packages and many thousands more individual package versions, it's a big lift to do that. I believe John recently had to do that for a change and it was not exactly fun. I've done similar scans when the repo was smaller and it still took several hours to complete.

Unless a repo scan is the only option for fixing something, it should be avoided; Not only because it may take significant time, or is logistically challenging (because new package versions are being added as the scan is performed, lag time between getting client updates and pkgs updates, etc.) but the implication of such a scan being required is that the change is a breaking change in some way