Spec for #1984 - Apps & Packages #2204
Conversation
| #### Job-to-be-done | ||
|
|
||
| 1. Update a package to the latest version | ||
| 2. Roll back to a previous version of a package |
There was a problem hiding this comment.
How do you want dependencies to be handled when rolling back? If Package Bv3.0 depends on Package Av2.0. Package A is rolled back to v1.0. What should happen to package B? Should it roll back? Should the roll back terminate with an unsuccessful message because other packages need to be rolled back?
There was a problem hiding this comment.
This is a really interesting edge case - good call out. Let's see what works best for various workflows. My gut says we should have a design that alerts the user that the package they intend to roll-back has dependencies and allow the user to determine yes/no to continue or not.
|
I've made the updates to explicitly state that the msstore source packages will only support updating to the latest version and uninstall. I think this spec is in a pretty good state now. |
| | --- | -------- | -------- | | ||
| | 1 | A user can view application name, publisher, size, version, and source | 0 | | ||
| | 2 | A user can switch between different versions of a package | 0 | | ||
| | 3 | A user can select multiple applications at a time to perform bulk actions like update or uninstall | 0 | |
There was a problem hiding this comment.
When the user clicks for an update, is the update going to default to "Silent" experience or "Silent With Progress" or an "Interactive" one? Some packages do not behave well in a silent installation (can default to installing in another location, may overwrite existing user configs) but expose the ability to select those options in an interactive install/update. How would the install modes be honored in a "bulk update" scenario? Can it be possible to set a preference only for specific packages that a user knows do not behave well in a certain install mode?
I think there should be a way to specify an install mode for an install/update and set a default install mode in user settings (where DevHome would try to honor the install mode if the installer supports it). There should be ways to offer a better UX if an installer doesn't support one of these modes. For this, we may need to populate winget manifests better with InstalModes: field. Not sure if this is within the scope of this spec / future consideration but wanted to call this out in any case
Summary of the pull request
This is the spec for #1984 - we will likely need to revisit and update certain aspects, but overall it outlines the key features and expected requirements for this functionality.
References and relevant issues
Detailed description of the pull request / Additional comments
Validation steps performed
PR checklist