microsoft / microsoft/winget-cli
Documentation when installer types change
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 26.4k
- Forks
- 1.8k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 15
Description
When installer types change between versions of packages, WinGet displays:
A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.
This causes users to be frustrated and or confused. Documentation should be added to Microsoft Learn for this case so users can be informed about the options, and the reasons for WinGet's behavior. In addition, an aka.ms URL should be added to the error message output so users can get more information and understand their options.
The choice was made to handle installer type changes by informing the user. If the manifest indicated "uninstall previous" was the default behavior, then the previous version would be removed and the newer version would be installed. This is a case where a user might want "both" versions to remain, or the user might "need" both versions to remain (at least until any package specific data was migrated).
WinGet needs to have some "default" behavior in cases where the consequences of installing a newer version of an arbitrary package might not be well understood. Arguments like "--force" and "--uninstall-previous" are present so a user can control WinGet's behavior.
I completely get the frustration here, and I encounter it myself regularly when installing and updating all kinds of packages. WinGet doesn't special-case behaviors for specific packages or publishers (not even Microsoft as a publisher). Our goal is to make the best "default" choice, so users aren't sad/mad/frustrated. Sometimes there isn't a single best solution, and in those cases, we defer to the user.
Dealing with decades of entropy in terms of legacy installers, and a world of change isn't easy. I don't have all the answers. That's one of the primary benefits of being open source and having these kinds of discussions. If we can come up with better solutions together, everyone benefits.
I do appreciate the honest feedback, even when it's negative. Thank you for taking the time to share it.
Originally posted by @denelon in https://github.com/microsoft/winget-cli/discussions/2155#discussioncomment-9168359
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the WinGet CLI error output described in the issue and the corresponding Microsoft Learn documentation. Document why installer-type changes require user choice and explain the available options; add an aka.ms link to the message, then verify both the published guidance and displayed error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100