winget-cli
winget-cli copied to clipboard
support versioning: major.minor.patch.int-somestring
Description of the new feature/enhancement
currently windows packages know major.minor.patch as version and major.minor.patch.someInteger is allwoed. which is a perfect fit for a central source code repository. nowadays git is used and there is no straight versioning any more. so it would be convenient to somehow include the git-hash in the versioning scheme. well known is to add the distance since the last branch (e.g. 10 commits) and the hash. which may make something like 1.20.3-10-adsfa. or 1.20.3.10-asdfa .
please support such versions.
Proposed technical implementation details (optional)
be as compatible with what was before, and allow adding a "-" and some arbitrary string, so the format is: int.int.int.int-arbitraryString
@soloturn we're working through some challenges with versioning. Not all software supports semantic versioning. We're looking at adding some additional metadata in the manifests to help with better matching against Add / Remove Programs where the "list" command is trying to match installed Apps against package manifests. This might get marked as a duplicate, but I'll keep it in the backlog for now until we consolidate the feature requests.
An example:
@hl2guide thanks for moving the image. We are also looking at adding some additional keys in the manifest to improve matching with Add/Remove Programs (ARP) matching. The AnyDesk example is a perfect one for a version number.
Here is yet another example (Adobe Acrobat Reader):
@ChrisLynchHPE I haven't looked to see how many manifests are in place for Adobe.AdobeAcrobatReaderDC, but there may be a workaround here. If the manifest for versions 21.y.z are added, and the ones for 2021.y.z are removed, the logic for comparing versions in "list" would see a match for the latest version. As long as something greater than 21.y.z exists in a manifest, that would continue to show as the "latest" version.
Updated example:
@denelon - Was this resolved with 1.3 and ARP version mapping?
I believe some of the cases are covered, but not necessarily all.
@soloturn can you test with Windows Package Manager 1.3 and let us know if these issues have been resolved?
@denelon After installing Visual Studio Community 2022 version 17.3.0 I run into more version mismatches in winget and an issue with the character "<".
PS C:\Users\Dean> winget --version
v1.3.2091
PS C:\Users\Dean> winget upgrade
Name Id Version Available Source
---------------------------------------------------------------------------------------------------------------------------------------
AnyDesk AnyDeskSoftwareGmbH.AnyDesk < ad 7.0.13 ad 7.0.13 winget
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148 Microsoft.VC++2008Redist-x86 9.0.30729.4148 9.0.30729.6161 winget
Microsoft Windows Desktop Runtime - 3.1.28 (x64) Microsoft.DotNet.DesktopRuntime.6 < 6.0.5 6.0.8 winget
Windows Software Development Kit - Windows 10.0.19041.685 Microsoft.WindowsSDK < 10.0.22000.832 10.0.22621.1 winget
Microsoft .NET SDK 6.0.303 (x64) Microsoft.DotNet.SDK.6 6.0.303 6.0.400 winget
5 upgrades available.
1 package has a version number that cannot be determined. Using "--include-unknown" may show more results.
Please consider cleaning up the client detected version by removing invalid characters.
Also there's an issue with multiple versions of an app being installed.
e.g. .NET SDK
The "<" character happens when the AppsAndFeaturesEntries are not defined for all versions of a package in the source; I'll take a look at cleaning up those packages in the winget-pkgs repository.
Multiple versions of an app is currently being tracked by #2129
The only "invalid" entry I see in the screenshot is the Anydesk package, which is being tracked by #2394
@hl2guide the "<" character was added to indicate the version installed on the system is earlier than any of the manifests in the community repository. @JohnMcPMS to keep me honest here. This was added because the manifests are using the "AppsAndFeatures" "displayVersion" entry for version comparison. The "packageVersion" is no longer required to match the Windows Apps & Features entry. In cases where manifests have these "marking" versions, we don't know how to reason about what the marking version would be for an earlier version of an installed package if we don't have the corresponding manifest.
@Trenly you beat me by 7 seconds 😂
@Trenly you beat me by 7 seconds 😂
You added more detail around ARP entries though ;)
@soloturn this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.