anchor.diff:  kind: ClusterServiceVersion
   metadata:
     annotations:
  -    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "4.8"}]' <1>
  +    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' <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.
  +<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}:
   +
  
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: 
  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]
  ====
  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
  
  - An existing Operator project
  
  .Procedure
  
  . 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]
  