Skip to content
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

Documentation when installer types change #4391

Open
denelon opened this issue Apr 19, 2024 · 3 comments
Open

Documentation when installer types change #4391

denelon opened this issue Apr 19, 2024 · 3 comments
Labels
Area-Output Issue related to CLI output Command-Upgrade Issue related to WinGet Upgrade Issue-Docs It's a documentation issue that really should be on MicrosoftDocs

Comments

@denelon
Copy link
Contributor

denelon commented Apr 19, 2024

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 #2155 (reply in thread)

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Apr 19, 2024
@denelon denelon added Issue-Docs It's a documentation issue that really should be on MicrosoftDocs Command-Upgrade Issue related to WinGet Upgrade Area-Output Issue related to CLI output and removed Needs-Triage Issue need to be triaged labels Apr 19, 2024
@huyz
Copy link

huyz commented Apr 19, 2024

Would it also be a good idea to detect and inform the user what the other "installer technology" is, even if only possible part of the time?

@denelon
Copy link
Contributor Author

denelon commented Apr 19, 2024

I'm open to that. I don't know users necessarily understand, but if we're linking to documentation with guidance they could certainly learn. WinGet does know the installer type for the currently installed version in almost every case, and it does know the new type based on the manifest for the newer version, otherwise the error message wouldn't be possible.

@huyz
Copy link

huyz commented Apr 20, 2024

I think it would go a long way. I don't have a problem with having to uninstall. I just have a problem with not knowing what the next step is. If I knew how something was installed, I'd have a better idea of what to do next

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Output Issue related to CLI output Command-Upgrade Issue related to WinGet Upgrade Issue-Docs It's a documentation issue that really should be on MicrosoftDocs
Projects
None yet
Development

No branches or pull requests

2 participants