You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a bundle has dependencies, installation is straightforward: install them all. What use cases do we have and want to support for other actions such as upgrade, custom actions and uninstall?
The text was updated successfully, but these errors were encountered:
One thought is that it is up to the calling tool to decide when to resolve a dependency graph. It makes sense for a tool to always resolve it for install, but for upgrade, if the bundle definition didn't change, then there may not be a need to resolve it again. However if the bundle definition changed while upgrading, the tooling could pass in the existing installations resolved previously to ensure they still meet the bundle interface and requirements while also resolving any new dependencies.
For custom actions, one option would be to look for matching custom actions in the graph and execute them, but not all bundles must define that custom action.
We discussed in today's general meeting how a parent bundle can coordinate calling custom actions on child dependencies and ultimately decided that would be a responsibility of the invocation image, that we probably don't provide enough information to a bundle to accomplish that and is ultimately is out of scope.
When a bundle has dependencies, installation is straightforward: install them all. What use cases do we have and want to support for other actions such as upgrade, custom actions and uninstall?
The text was updated successfully, but these errors were encountered: