1. Proposed title of this feature request

Give OLM-operator maintainers the ability to share supported-OCP version constraints

2. What is the nature and description of the request?

Provide a mechanism for OLM-installed operator maintainers to say things like:

And if you exceed this, you will lose the data this operator had been maintaining, and recovery will be really rough.

or:

Maybe this operator would be fine with that OCP release, but we haven't gotten around to testing yet. Once we test and have a release we are confident we can support across both your current OCP version and those later OCP 4.ys, we'll cut a new release of our operator to let you know.

so that cluster admins can make more informed choices about what would happen to their OLM-installed operators if they update their OCP cluster to 4.(y+1). And also what options they have, e.g. for updating their OLM-installed operators first, if they want to update to that 4.(y+1) OCP with a happier prognosis, if they are not comfortable with the current predictions.

3. Why does the customer need this? (List the business requirements here)

There's an existing olm.maxOpenShiftVersion, but it's just the version, and there's no way today for the maintainers of an OLM-installed operator to give cluster admins additional information messages alongside that version cap.

There are also olm.deprecations, and while those are currently about the current OLM-installed operator vs. the current host cluster, they could possibly be extended to cover the current OLM-installed operator vs. possible future host cluster OCP versions.

4. List any affected packages or components.

OLM (v1?) would need to provide a mechanism for communicating this context and the maintainers of some subset of OLM-installed operators would need to populate the data. Existing mechanisms like ClusterOperator Upgradeable conditions will handle piping the data up from OLM to cluster admins considering OCP updates, once OLM has the context to share.