In the current context, the Cluster Observability Operator makes available a single stable operator channel available, in like with the current rolling release strategy.

• Having a single stable channel, however, adds unnecessary complexity to gitops-like automation scenarios, particularly when we need to rollback to specific CCO version: i.e. like needing to rollback to 1.0.0 due to the currently work-in-progress COO-784

Having a dedicated per-minor stable-1.x channel grants a more granular to customer more control and enable them to decide when to manually introduce "breaking" changes on-demand by switching the channel from "stable-1.x" to "stable-1.x+1".