Goal:
Today opm <index | registry> <prune | rm> is an all or nothing operation, the entire operator package is removed from the database (for rm), and every operator package except the specified ones are removed (for prune).  Ideally it would be good to specify versions of what is being removed, so that you can remove a single version of an operator from the table instead of the entire package.
 
E.X.: opm registry rm --operators my-operator --version-range ">=1.0.0 =<1.1.0"
 
Problem:
 
The problem today is if I create an operator catalog index that has a single bad version of an operator bundle in it that needs to be hotfixed for a client, then I need to remove the entire operator package from the catalog.  It would be more efficient, less intrusive, and less error prone to be able to remove only a single version or version range of an operator bundle from the index.  
 
Example today:
 
1. Create new version of catalog
2. Customer installs
3. Customer finds an error in OLM metadata for the install (maybe wrong replaces specified)
4.  Use the opm rm feature to remove the bad operator package
5. Patch back into the catalog all the old working bundle versions, and the hot fixed versions
 
Example desired:
 
1. Create new version of catalog
2. Customer installs
3. Customer finds an error in OLM metadata for the install (maybe wrong replaces specified)
4.  Use the opm rm feature to remove the bad operator package and a specific version of that package
5. Patch back into the catalog hot fixed version(s)
 
Why is this Important:
 
This is important because for teams that are part of a curated catalog, they may not own the catalog build process.  If they intercept a catalog, and do not own the process to create the catalog a hot-fix process is needed to fix emergency situations.  If Operator A releases a bundle version with a dependency error (requires a non-existent CRD), and this is brought into a curated catalog (that they do not own build process for), then the only way to deliver a quick fix for this (before a real Z build can be delivered) is to do the following: Create a subset of the curated catalog with the bad package removed, patch in a bundle for the operator package with the hot-fix, spin of the fix on the cluster. 
 
Dependencies (internal and external):

• opm
• olm
   
  Acceptance Criteria: * Ability to remove an operator version from a catalog (instead of the entire package)

• Ability to prune a set of versions of operator packages from a catalog