Goal: Make OLM's dependency model more intuitive, flexible and transparent. Allow Operator developers to be very specific about the Operator they depend on. Make it easier for admins to preview what is going to be resolved. Make the InstallPlan more intuitive.

Benefit Hypothesis: Get more Operator authors to buy into OLM dependency management to simplify their installation and update routines.

Why is this important: OLM dependency resolution is too inflexible for many Operator authors who want to be more specific about the Operator they depend on. APIs are not precise enough to hit on a particularly well tested dependency. It is also too hard for cluster admins to discover what is about/what has been installed as a dependency, additional Operators being installed comes as a surprise and the relationship is not made clear.
It is also hard to understand for admins that the resolution at the scope of a namespace level and in turn InstallPlans working at that scope.

Open Question:

• Do we want to cover setting channel and approval strategy for dependencies in this or not?
• What are the other gaps for Red Hat Operators using OLM dependencies?

Acceptance criteria:

• Operator developers can specify exactly which version(s) of a dependency they require
• OLM dependency resolution results are exposed to the cluster admin