Standarized package versions

[KorbenDev]

In order to automate installation and updates of packages it would be nice to have standarized versioning in repostiory.

To check if a package has been updated in repository and if an update should be triggered, a comparison of installed and avalaible versions would be preferable.
I use the System.Version class to do this (seems the correct way). But some packages currently use strange version strings. e.g. Windscibe:
Name Id Version
----------------------------------------------
Windscribe Windscribe.Windscribe 1.83 Build 18

A rule to enforce standarized versioning would make package handling so much easier...
major.minor.build.revision

Environment:
PS E:> winget --info
Windows Package Manager v0.1.41331 Vorschau
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.264
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

[aetos382]

Should package be versioned with semantic versioning?

If winget supports automatic installation of dependent packages (#163), the package manifest should be able to claim which version of the dependent package this package is compatible with.

[megamorf]

If winget were to enforce semantic versioning I think the challenge would be to match the manifest versions to package versions of vendors that don't actually use semver for their versioning.

[KorbenDev]

The package version should match the vendor version, if possible. But: it does not have to.
Example: you package a software A 1.1.1.1000 as package A 1.1.1.1000. Then you find an error in the package. So now you publish it as package 1.1.1.1001 or 1.1.1.2000.
Not pretty, but practical.
An alternative solution may be to add a publishing date. But me personally likes the strict versioning better.

[denelon]

I am also a fan of semantic versioning, but we can't shouldn't impose that on other software producers wanting to add software to the community repository. Our primary goal is to make sure the logic we use to determine the latest version of a package works in a predictable manner.

[KorbenDev]

@denelon I agree, you can't. BUT: package version does not have to be the same as software version. Of course, in an ideal case they would get along, but if not, that's also ok, imo. To avoid confusion about the version of the application, a separate software version property (or package version) could be added to the manifest. But the package version should be semantic and easy to use for further processing.
Edit: to do this, you don't have to change current packages. Just add a package version property to manifests (if not set, use a default 1.0.0.0).
Just take a look on all software deployment solutions out there. As far as I know (I know at leat 4), they all use internal versions/revisions independent of software versions.

[aetos382]

The benefit of Semantic Versioning is that it can tell me if a new version is compatible with a previous version or not.
If I can get that information in a separate field, there is no need to include it in the version number.
I would suggest including an optional field in the manifest to indicate which current version is compatible with which versions in the past.

If manifests use Semantic Versioning independently of the application version, and the application doesn't comply with it, then those version numbers could be several major versions distant.
We think it would be confusing for winget users to provide both of those version numbers.

[KorbenDev]

I agree with you for the most part. But: if you fear that winget users get confused by providing two different version numbers, how much confusion would you expect if they have to provide compatible versions? That optional field will barely be filled.
And I think the compatibility aspect is more an issue between different packages and dependencies than between package versions itself. Even more reason for me to enforce semantic versioning in the first place. The additional property was just kind of a peace offering. Yes, there might be some kind of inprecsion due to a conversion of a publisher version, but the benefit, imo, is much bigger.
You can't support dependencies without semantic versioning, can you? If you don't plan to support dependencies, that's fine. But I think it would be short sighted and would limit wingets future deeply.

[aetos382]

I have also commented on several other issues on what needs to be considered to support package dependencies.
And for that reason, I don't think Semantic Versioning is necessarily necessary.