Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Winget upgrade doesn't recognize preview versions #5267

Open
jaliyaudagedara opened this issue Mar 2, 2025 · 1 comment
Open

Winget upgrade doesn't recognize preview versions #5267

jaliyaudagedara opened this issue Mar 2, 2025 · 1 comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@jaliyaudagedara
Copy link

jaliyaudagedara commented Mar 2, 2025

Brief description of your issue

I have Visual Studio 17.14.0 Preview 1.1 installed.

winget upgrade shows Visual Studio 17.14.0 as an available upgrade.

Here 7.14.0 Preview 1.1 > 17.14.0.
Image

Steps to reproduce

N/A

Expected behavior

Previews versions should be considered when determining available updates.

Actual behavior

Previews versions are not considered when determining available updates.

Environment

> winget --info
Windows Package Manager v1.10.320
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.3194
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.320.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\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
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

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
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Mar 2, 2025
@Trenly
Copy link
Contributor

Trenly commented Mar 2, 2025

This is actually correct behavior due to how version Parsing works in WinGet.

WinGet splits the version into parts by the periods, and compares each part one at a time to determine which is greater. In this case, the comparison that determines the version order is between .0 and .0 Preview 1. Since preview versions are generally released before stable versions, the preview versions are considered a lower version (in fact, any string value after .0 would cause that version to be sorted lower)

I will note, however, that 17.14.0 does not appear on the release history page, which in this case means that whomever submitted the manifest to winget-pkgs likely made an error in the manifest, or the preview versions need stronger versioning for what the preview versions write to the registry

@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Triage Issue need to be triaged label Mar 2, 2025
@denelon denelon added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Mar 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

3 participants