anchor.diff:  
   The following procedure helps prevent administrators from installing versions of your Operator on an incompatible version of {product-title}. These steps also prevent administrators from upgrading to a newer version of {product-title} that is incompatible with the version of your Operator that is currently installed on their cluster.
   
  +This procedure 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 defining the cluster versions where the Operator should be distributed, you ensure that the Operator does not appear in a catalog of a cluster version which is outside of the allowed range.
  +
   [IMPORTANT]
   ====
  -You should configure the following settings in your Operator project as soon as possible. Users running workloads with deprecated APIs that are planning to eventually upgrade to a future version of {product-title} must be running an Operator that has the proper configuration to avoid a cluster upgrade to an incompatible version and potentially adversely impact their critical workloads.
  +Operators that use deprecated APIs can adversely impact critical workloads when cluster administrators upgrade to a future version of {product-title} where the API is no longer supported. If your Operator is using deprecated APIs, you should configure the following settings in your Operator project as soon as possible.
   ====
   
   .Prerequisites
   
  -- Operator SDK CLI installed on a development workstation
  -- Operator project initialized by using the Operator SDK
  +- An existing Operator project
   
   .Procedure
   
  -. Configure the maximum version of {product-title} that your Operator is compatible with. In your Operator project's cluster service version (CSV), set the `olm.openShiftMaxVersion` annotation to prevent administrators from upgrading their cluster before upgrading the installed Operator to a compatible version:
  +. If you know that a specific bundle of your Operator is not supported and will not work correctly on {product-title} later than a certain cluster version, configure the maximum version of {product-title} that your Operator is compatible with. In your Operator project's cluster service version (CSV), set the `olm.maxOpenShiftVersion` annotation to prevent administrators from upgrading their cluster before upgrading the installed Operator to a compatible version:
   +
   .Example CSV with `olm.maxOpenShiftVersion` annotation
   [source,yaml]
  
positive.code: kind: ClusterServiceVersion
  metadata:
    annotations:
      "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "4.8"}]' <1>
  ----
  <1> 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}:
  +
  
negative.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 Operator's bundle image. For example, if your project was generated using the Operator SDK, update the `bundle.Dockerfile` file:
  +
  .Example `bundle.Dockerfile` with compatible versions
  +
  [source,yaml]
  ----
  LABEL com.redhat.openshift.versions="<versions>" <1>
  ----
  <1> Set to a range or single version, for example, `v4.6-v4.8`. This setting defines 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.
  