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.

[denelon]

I changed it to a feature since the client is "doing the right thing". We can consider other mechanisms, but semantic versioning is a best practice.

[JoesCat]

Thanks @denelon, best guess is FontForge may have adapted a shortened format of yyyy-mm-dd format as that seen in webpages like this: https://sourceforge.net/p/fontforge/git/ci/master/tree/
This format has been consistent and steady with FontForge long before git and/or github existed, and it is pretty much expected by downstream users, distros, etc. therefore it makes sense to continue this way.
Agreed - Semantic versioning is best practice, but it sort of got lost along the way between 2012...2014, so you're back to yyyymmdd tags again.
libspiro and libuninameslist had a short period with added info but reverted back to the same YYYYMMDD format again as it was also commented the earlier format was preferred. These continue using semantic versioning.

[Trenly]

Thanks @denelon, best guess is FontForge may have adapted a shortened format of yyyy-mm-dd format as that seen in webpages like this: https://sourceforge.net/p/fontforge/git/ci/master/tree/
This format has been consistent and steady with FontForge long before git and/or github existed, and it is pretty much expected by downstream users, distros, etc. therefore it makes sense to continue this way.
Agreed - Semantic versioning is best practice, but it sort of got lost along the way between 2012...2014, so you're back to yyyymmdd tags again.
libspiro and libuninameslist had a short period with added info but reverted back to the same YYYYMMDD format again as it was also commented the earlier format was preferred. These continue using semantic versioning.

I think you're missing a key factor. YYYYMMDD would work and would sort properly since it would be strictly increasinc. FontForge is writing DDMMYYYY as its version in the registry, which is not strictly increasing

[denelon]

Yes, I think one option could be to have a "custom version format" type of enumeration to inform the client of how to "reason" about versioning. This also becomes an order of magnitude harder when the versioning schema changes for a package. We will clearly need a specification for this type of feature.

[DenWin]

I really do not see, how WinGet should be responsible for all potenital versioning schemas out there:

• there exists kind of a standard out there => semVer
• at the very least several sections, where each section is seperated by a dot and each section is sorted properly
• and then there are the more whimsical variants:
  • YYYY/DD/MM
  • YYYY/MM/DD
  • DD/MM/YYYY
  • MM/DD/YYYY
  • all variants with dots, dash or any other character
  • VersionA, VersionB, VersionC
  • no versioning at all, but - for some reason - only GUID's (*1)
  • .... and what else someone can envision

how is Winget suppose to understand all these and there already exist an path forward with the current manifest:

1. setup your own versioning in WinGetPckgs
2. add AppsAndFeaturesEntries with the proper DisplayVersion coming from the application

I have analysed the versioning in WinGet in some details here: #3073 (comment)

The only thing missing would be to document this approach properly and communicate that documentation!

---

*) Well, I doubt, anyone would use GUID's as their versioning strategy but I added that one to hit my point: there will always be the one strategy nobody has thought about before!

[Trenly]

there will always be the one strategy nobody has thought about before!

^ That is exactly the point. One of the core tenets of Winget has always been to meet developers where they are. There are many applications out there which do not use semVer, and I actually have seen applications where the version is the first few characters of the commit hash.

WinGet should have some way to gracefully handle these weird scenarios, and currently it does not. However, I do think that there is a "quick" fix for this that would allow WinGet to have its own internal version number association for packages with weird versions -

• Separate "PackageVersion" from "Marketing Version" #3061
• Spec 3061 - Marketing Version #3062

Either way, it doesn’t hurt to keep this issue open as a potential considerarion until there is a formal decision from the engineering team that this is something which they are choosing not to implement

[Trenly]

[Policy] Area-Output
[Policy] Area-Sorting