anchor.diff:  
   [IMPORTANT]
   ====
  -Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. As a result, your Operator projects are unable to use removed APIs starting with the version of {product-title} that uses the Kubernetes version that removed the API.
  +Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. If your Operator is using a deprecated API, it might no longer work after the {product-title} cluster is upgraded to the Kubernetes version where the API has been removed.
   
  -As an Operator author, it is strongly recommended that you review the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/[Deprecated API Migration Guide] in Kubernetes documentation and keep your projects up to date to avoid using deprecated and removed APIs. Ideally, you should update your Operator before the release of a future version of {product-title} that would make the Operator incompatible.
  +As an Operator author, it is strongly recommended that you review the link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/[Deprecated API Migration Guide] in Kubernetes documentation and keep your Operator projects up to date to avoid using deprecated and removed APIs. Ideally, you should update your Operator before the release of a future version of {product-title} that would make the Operator incompatible.
   ====
   
   When an API is removed from an {product-title} version, Operators running on that cluster version that are still using removed APIs will no longer work properly. As an Operator author, you should plan to update your Operator projects to accommodate API deprecation and removal to avoid interruptions for users of your Operator.
  
positive.code: ----
  <1> Set to a range or single version.
  
  .. To prevent your bundle from being carried on to an incompatible version of {product-title}, ensure that the index image is generated with the proper `com.redhat.openshift.versions` label in your project's `bundle.Dockerfile`:
  +
  .Example `bundle.Dockerfile` with compatible versions
  +
  [source,yaml]
  ----
  LABEL com.redhat.openshift.versions="v4.6-v4.8" <1>
  ----
  <1> Set to a range or single version.
  +
  [NOTE]
  ====
  This label is also useful when you know that the current version of your Operator will not work well, for any reason, on a specific {product-title} version. By using it, you define the cluster versions where the Operator should be distributed, and the Operator does not appear in a catalog of a cluster version which is outside of the range.
  ====
  
  You can now bundle a new version of your Operator and publish the updated version to a catalog for distribution.
  
negative.code: kind: ClusterServiceVersion
  metadata:
    annotations:
      "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' <1>
  ----
  <1> Specify the maximum cluster version of {product-title} that your Operator is compatible with. For example, setting `value` to `4.8` prevents cluster upgrades to {product-title} versions later than 4.8 when this bundle is installed on a cluster.
  
  . If your bundle is intended for distribution in a Red Hat-provided Operator catalog, configure the compatible versions of {product-title} for your Operator by setting the following properties. This configuration ensures your Operator is only included in catalogs that target compatible versions of {product-title}:
  +
  