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: 
  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.
  
  [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.
  ====
  
  .Prerequisites
  
  - Operator SDK CLI installed on a development workstation
  - Operator project initialized by using the Operator SDK
  
  .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:
  +
  .Example CSV with `olm.maxOpenShiftVersion` annotation
  [source,yaml]
  
negative.code: 
  [IMPORTANT]
  ====
  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 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.
  