`com.redhat.openshift.versions` ensures the operator is only included in catalogs that target compatible versions of OpenShift Container Platform. At this moment we're using `com.redhat.openshift.versions` with a single version which indicates that the operator is supported on that version of OpenShift or later.

The idea is to start using `com.redhat.openshift.versions` with a range, in order to also define the upper limit. (https://redhat-connect.gitbook.io/certified-operator-guide/ocp-deployment/operator-metadata/bundle-directory/managing-openshift-versions)

`olm.maxOpenShiftVersion` ensures the openshift cannot be upgraded to a higher version than stated in a cluster where 3scale is installed.

https://docs.openshift.com/container-platform/4.8/operators/operator_sdk/osdk-working-bundle-images.html#osdk-control-compat_osdk-working-bundle-images

pros:

• Protects customers (and support) from getting into a situation where 3scale is incompatible with OpenShift
• Is easy for operator team to update

cons:

• Prevents customers from updating OpenShift until new 3scale release comes out.
• Puts more pressure on engineering to release (at least a patch) when new OpenShift has been released

Further actions to help decide:

• Ask around what other on prem products do
• What would be the effect for Red Hat managed OpenShift?
• Ask some 3scale customers of which we know they aggressively stay on latest OpenShift (if we have that info)

cc: amasferr