-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
winget upgrade returns non-valid version numbers for some packages (v1.1.13405) #1856
Comments
@o-l-a-v we've run into plenty of strange version numbers attempting to meet developers where they are. We've also encountered subtle differences between a "marketing" package version and the version reported in Windows Apps & Features. We're still working on the implementation for the 1.1 schema so we can have a rational separation between these two types of software versions. Here is an example where build numbers might use dates, product codes, and branch numbers: https://plugins.jetbrains.com/docs/intellij/build-number-ranges.html Versions today are essentially just "strings' we attempt to reason about as best we can. We've had a few different issues submitted related to versioning. We're also looking at how we may handle this in the PowerShell cmdlets. Unfortunately, not all software adheres to https://semver.org. |
It looks like OBS Studio is either not performing an upgrade including updating registry keys, or it's doing a side-by-side install and the older version is still present. The same appears to be true for PostgreSQL. Teams is a unique one. If Teams is installed in "user" scope, the Machine Wide Installer is first installed, and we're getting a false match for an upgrade to the machine wide installer even if you have the latest (or a newer) version installed. We've got some improvements coming for the |
I'm actually seeing an interesting issue with Jetbrains ReSharper tools after I updated them to 2022.3 via Jetbrains Toolbox.
|
Hey all, we've done a lot of work around versioning so WinGet can deal with non-semantic versions. Manifests can include a marketing version as well as a package version so it can properly reason about logical upgrades. There are no gurantees or requirements for versions in WinGet to be of type [System.Version]. I'm going to go ahead and close this issue. If this is something you feel is absolutely necessary, we'd consider it for something related to the PowerShell cmdlets. Please create a new issue if that's the case so we can have a discussion about how we might handle the scenario in the future. Even WinGet prepends "v" on versions which isn't technically correct, but it represents a breaking change if/when we fix it. |
Today,
winget upgrade
returned a list of applications where some of the version numbers are not valid. As in converting them to[System.Version]
in PowerShell fails. I can't remember having this issue before.Packages in this example
Presenting valid version numbers should be something we can take for granted when using a package manager IMO. Either the manifest tests should pick this up (not accept commits where version number is following valid version format), and/ or winget-cli should parse the version numbers before showing them in the terminal.
Raw output from
winget upgrade
Environment
winget --version
winget --info
Why is this important?
Until
winget-cli
provides the ability to output results to a standardized format, like JSON or CSV, people trying to usewinget-cli
with other tools, like Intune (example: https://github.com/o-l-a-v/winget-intune-win32), must try to parse the output.Another example: I've made a PowerShell script to update just certain packages, like skipping Microsoft Office ProPlus. Handling all the special problems currently present in winget-cli, like
winget upgrade --id <id>
not working for a lot of packages, and now the version numbers not being standardized, the logic is starting to get ugly. Current script right now:Click to show
The text was updated successfully, but these errors were encountered: