Version number sorting

[krystofkrticka]

Brief description of your issue

If version number of package contains dashes, winget will sort it incorrectly and will think that for example older version is latest instead of latest version.

This is issue with temporal version according to @stephengillie in this PR microsoft/winget-pkgs#93519 (comment)

FontForge.FontForge package is affected by this issue because it's versions are looking like this (08-03-2022, 01-01-2023, etc.) This can be seen in this snapshot of repo https://github.com/microsoft/winget-pkgs/tree/473159531f3618f21a7b89151fb181d0632c59df/manifests/f/FontForge/FontForge

Steps to reproduce

Install latest fontforge.
List update using winget upgrade
It'll show version 08-03-2022 as latest despite having version 01-01-2023.

Expected behavior

Running winget upgrade should not show that update is available if version 01-01-2023 is already installed

Actual behavior

Running winget upgrade shows that upgrade is available as version 08-03-2022.

Environment

Windows: Windows.Desktop v10.0.22621.1105
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.101.0

[krystofkrticka]

Sorry I closed this issue because I thought that I posted it in wrong repo.

[Trenly]

Just my two cents here - I don't believe this is truly a bug in the sorting. Because they use the format of --, the day is the first part of the version compared. So, when looking at it as a version, '08' is higher than '01', and it makes sense that 08-03-2022 would be deemed newer. Even PowerShell uses this logic when comparing the two -

PS D:\Trenly> '01-01-2023' -gt '08-03-2022'
False

In fact, if the publisher were to have a release on December 31st, then versions would only be detected as newer if they were released on December 31st of the following year, since 31-12-XXXX would be greater than any other combination of day and month possible.

I think the primary issue here is the publisher is not using a semantic version, meaning that standard version comparisons will almost always fail. You can see they get around this in their GitHub releases by using the year, then the month, then the day. This is partially why we can use the GitHub tag as the Marketing Version over at winget-pkgs - since YYYY-mm-dd will always be increasing. I've filed an issue on their GitHub repo to switch the order of their versioning in the registry fontforge/fontforge#5178

[krystofkrticka]

Yes, their versioning which is reported to windows is honestly kind of dumb. If they really want do use date as version number they should use date according to ISO 8601. Which was created with this in mind yet some developers ignore it.

[Trenly]

Yes, their versioning which is reported to windows is honestly kind of dumb. If they really want do use date as version number they should use date according to ISO 8601. Which was created with this in mind yet some developers ignore it.

Perhaps this issue should be kept open - there may be ways for version parsing to be improved. It may be possible to attempt parsing versions as dates if they are of the format XX-XX-XXXX

[krystofkrticka]

OK I'll leave it open than.

[krystofkrticka]

I'll never understand why is somebody opting to use date in regional format as version number instead of standardized format.

[krystofkrticka]

And honestly I need to stop using wingetcreate to add or update packages in winget and start using YAMLcreate which is much more advanced and even easier to use when comes to adding additional information to manifests.