// Module included in the following assemblies:
//
// * extensions/ce/update-paths.adoc

:_mod-docs-content-type: CONCEPT
[id="olmv1-ocp-compat_{context}"]
= Compatibility with {product-title} versions

Before cluster administrators can update their {product-title} cluster to its next minor version, they must ensure that all installed Operators are updated to a bundle version that is compatible with the cluster's next minor version (4.y+1).

For example, Kubernetes periodically deprecates certain APIs that are removed in subsequent releases. If an extension is using a deprecated API, it might no longer work after the {product-title} cluster is updated to the Kubernetes version where the API has been removed.

If an Operator author knows that a specific bundle version is not supported and will not work correctly, for any reason, on {product-title} later than a certain cluster minor version, they can configure the maximum version of {product-title} that their Operator is compatible with.

In the Operator project's cluster service version (CSV), authors can set the `olm.maxOpenShiftVersion` annotation to prevent administrators from updating the cluster before updating the installed Operator to a compatible version.

.Example CSV with `olm.maxOpenShiftVersion` annotation
[source,yaml]
----
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  annotations:
    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' <1>
----
<1> Specifies the latest minor version of {product-title} (4.y) that an Operator is compatible with. For example, setting `value` to `{product-version}` prevents cluster updates to minor versions later than {product-version} when this bundle is installed on a cluster.
+
If the `olm.maxOpenShiftVersion` field is omitted, cluster updates are not blocked by this Operator.

[NOTE]
====
When determining a cluster's next minor version (4.y+1), {olmv1} only considers major and minor versions (x and y) for comparisons. It ignores any _z-stream_ versions (4.y.z), also known as patch releases, or pre-release versions.

For example, if the cluster's current version is `{product-version}.0`, the next minor version is `{ocp-nplus1}`. If the current version is `{product-version}.0-rc1`, the next minor version is still `{ocp-nplus1}`.
====