Normalized and Standardized Version Numbers

[hl2guide]

Description of the new feature/enhancement

Normalization of version number format to fix inconsistencies.

e.g.:

Proposed technical implementation details (optional)

• Improvement of detecting actual installed version of a software package
• Cleaning of the version number to a standardized ruleset

[denelon]

This looks like a duplicate of https://github.com/microsoft/winget-cli/issues/981

[denelon]

@hl2guide the image you included is very helpful. If you don't mind, add it to the other issue and add your 👍. If you believe this is a duplicate, please close it. If not, let me know what you feel is different here.

[hl2guide]

@denelon I'd consider this seperate as that issue is more about a git formatted versioning, where this issue is more about the smart handling of different versioning schemes (a reaction) for substrings.

e.g.:

The normal ones [easier to handle and compare]

• 1.2
• 1.2.3
• 1.2.3.4

The non-standard ones [needs special handling]

• alpha, beta, etc
• 1.1a
• Build 10
• unknown (not determined)

[denelon]

Yes, we're aware of the challenge with the various versioning mechanisms with software. It would be pretty fantastic for ISVs/Publishers to adopt semantic versioning. We are also working through best practices for packages that essentially get treated as different packages for "major" releases. Programming languages and compilers routinely fall into this category. We currently separate version strings into tokens and sort by each token in sequence. It's an attempt at treating versions semantically.

We also have some interesting challenges with "preview" versions of software with special strings for versions like these, and how to deal with software that can be installed "side by side" like Visual Studio Code, and software that cannot like Docker Desktop.

[LeonarddeR]

Especially for software authors, it would be very helpful to know how winget calculates whether a package can be upgraded or not. For example, the NVDA screen reader for the blind has a versioning scheme of year.major.minor, e.g. 2021.1.1, where the minor part is optional. The full versioning scheme is year.major.minor.build, e.g. 2021.1.1.22000. For alpha en beta versions, the display version is in the form alpha-22966,091b315e, whereas the file version is 2021.2.0.22966. Winget yet treats version 2020.4 as an update of version alpha-22966,091b315e. Documentation could help us in:

1. Changing what is registered in the uninstall registry key to satisfy winget, if necessary
2. Finding out why alpha-22966,091b315e is considered older than 2020.4. Is this a bug or by design?

[hl2guide]

Updated example:

[ItzLevvie]

f.lux and MEGAsync displaying "Unknown" is an issue that needs to be brought up to the applications' developers as the Windows Package Manager uses the values provided from the Control Panel - both of these applications don't show a version in Control Panel, therefore, the solution that the Windows Package Manager team can do here is to allow users to filter out versions that display as "Unknown" in the future or to solve it temporarily on the users' end they would've to add a DisplayVersion registry key in Microsoft\Windows\CurrentVersion\Uninstall.

Standard Notes may seem to be an issue with their installer as when I install the application using the Windows Package Manager, it shows up as 3.8.7 rather than 1.0 in Control Panel. Perhaps they may have a MSI installer that's reporting an incorrect version?

Unified Remote has now been temporarily removed from the repository, as it seems that there's a driver prompt blocking the install when ran from a clean installation of Windows and all manifests submitted into the repository must install the application in silent/unattended mode.

VLC uses different version numbers between the MSI installers, which shows up as 3.0.16.0, and the EXE installers, which shows up as 3.0.16. To solve this - it'll likely need to be split up into VideoLAN.VLC.exe and VideoLAN.VLC.msi in the repository.