1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/update-determining-the-cluster-version-update-path.adoc
Cavalle 64e845d54d TELCODOCS-2171-lifecycle-mgmt-lcavalle: Generalize Day2Ops Lifecycle management
TELCODOCS-2171-lifecycle-mgmt-lcavalle: fixing some vale errors
2026-01-13 16:57:30 +00:00

28 lines
1.3 KiB
Plaintext

// Module included in the following assemblies:
//
// * edge_computing/day_2_core_cnf_clusters/updating/update-api.adoc
:_mod-docs-content-type: PROCEDURE
[id="update-determining-the-cluster-version-update-path_{context}"]
= Determining the cluster version update path
[role="_abstract"]
Use the link:https://access.redhat.com/labs/ocpupgradegraph/update_path/[Red Hat {product-title} Update Graph] tool to determine if the path is valid for the z-stream release you want to update to.
[IMPORTANT]
====
The <4.y+1.z> or <4.y+2.z> version that you update to must have the same patch level as the <4.y.z> release you are updating from.
The {product-title} update process mandates that if a fix is present in a specific <4.y.z> release, then the that fix must be present in the <4.y+1.z> release that you update to.
====
.Bug fix backporting and the update graph
image::openshift-bug-fix-backporting-update-graph.png[Bug fix backporting and the update graph]
[IMPORTANT]
====
{product-title} development has a strict backport policy that prevents regressions.
For example, a bug must be fixed in 4.16.z before it is fixed in 4.15.z.
This means that the update graph does not allow for updates to chronologically older releases even if the minor version is greater, for example, updating from 4.15.24 to 4.16.2.
====