Package repository seems to need more quality control / consistency checking

[donid]

I have created a little WinForms Tool which allows the user to browse through all of the (currently more than 400 packages) in a gridview: https://github.com/donid/WingetRepoBrowser

This tool makes it easy to spot various quality / consistency issues. Some Examples:

• VisualStudio packages use 'devenv' or 'devenv.exe' as AppMoniker
• Nutstore has a comma separated list as AppMoniker
• firefox-esr has an AppMoniker, normal doesn't
• all older git packages have an AppMoniker, 2.62.2 doesn't
• OneDrive's AppMoniker changes casing between version (and Installer Arch and more)
• wireshark's licenseurl is hhttps://...
• the version property is not used in the recommended way (Foldit: 20180312-1714f56737-win_x86 / Windscribe: 1.83 Build 18)

I know that I could / should open an issue / PR for each (most) of those problems, but having found so many inconsistencies in just 400 packages hints that something should be changed on a larger scale. I don't know if those checks could be automated (with ML/AI?), or if the manual review process of PRs in the package repo has to be improved.

[latere-a-latere]

I don't think you can avoid straying off the recommended version format because software simply doesn't use a consistent numbering system. Some software uses the standard 1.5.2, others use something date related like 2020.1.15 and then you got others that include build numbers and other stuff.

[megamorf]

@marnicgit That's not what donid is saying. He's pointing out obvious inconsistencies in how the manifest field contents are maintained, i.e.:

• missing file extensions
• field separators
• missing fields
• case mismatches

And I agree, this should be handled by some automated process to ensure a decent level of consistency across all packages.

[donid]

@marnicgit I partly agree with you, and that is probably the reason why the manifest spec says 'should' instead of 'must'. But if versions don't use the recommended rule, it is very hard for a tool to sort packages by this property - e.g. to offer the latest version. That is one of the main reasons why I have created an issue proposing a 'ReleaseDate' property: microsoft/winget-cli#345
But in the case of 'Foldit' it is probably not a good idea to mix the architecture into the version number

[doctordns]

@donid If packages are to be managed, then reliable metadata is needed to enable packages to be managed. To be reliable and acceptable in a larger enterprise setting, I believe @megamorf is right that there must be a minimum standard (and some of those 'should's probably should be turned into 'musts'" to raise the bar so to speak) There must be a high minimum level spec of the metadata when a package is pulled and rejected if it falls short of the standard.

[chausner]

@donid I mostly agree with all the points you brought up. I happen to be the one who submitted both Foldit and Windscribe that you mentioned. In both cases, the version strings in the manifests are exactly as used by the applications. So as long as there is not a mandatory format that all version numbers have to follow, using whichever format the application uses is the most consistent rule we can follow, I think.

It's dangerous to simply change or leave out parts of the version. E.g. in the case of Windscribe, there are different releases which are discernible only by the build number.

[donid]

@chausner as you can see in #1454 (comment) I can relate to your point of view - only that the architecture is mentioned in the version-property of the package seems unfavorable to me.
Sorry, if it seems like I've been 'finger pointing' at your packages - I have just extended WingetRepoBrowser to show installer properties in aggregated form at the package level,
so I could extend the examples list from my first post quite a bit.
But let's not forget, winget is in an early stage, so there are a lot of things to be defined/sorted out.

[ericleigh007]

To enable winget (or any tool) to do automatic upgrades, it has to be able to tell when a version is newer than the current version. A release date would work, as suggested, but either a standardized version number, or a version number comparison algorithm (specified in the manifest) would be a lot better, as it would support more fine upgrade control.

Another option might be to allow the app to have its own displayed version, but also to have a winget-standard version as well (that MUST be a standard 1.2.3.4 version).

At any rate, yes, winget is new, and it has to deal with issues that are not present for other tools (like supporting packages in a bunch of older formats, and before "standard version numbering" was invented, but let's not use that as an excuse for having it all broken.

Great stuff, keep it up!