Feature Overview

• Starting with 4.TBD  and later all minor versions which are within supported skew limits may change channels once and repeatedly update being ensured that they'll end up running a controlplane version which matches the channel X.Y version. For example:

• • [example] A cluster running 4.16.z can change to fast-4.17, fast-4.18,fast-4.19 stable-4.17, stable-4.18, or stable-4.19, eus-4.18

This is important because customers currently associated "EUS-to-EUS" update pattern and the EUS channels with the requirement to have EUS entitlements where as that is not our intention. The hope is that by allowing clusters to freely change between all channels within skew limits it will be made clear that this is not a limit and we actually encourage applying multiple control plane updates with as few worker rolling updates as possible as a means to improve clusters ability to update across versions more rapidly and with less workload disruption.

Once we're ready to rollout this change we should amend documentation starting with 4.TBD to indicate that you can change to adjacent channels from multiple minor versions and highlight that the graph you're offered will be guide your cluster toward that version. If you wish to upgrade to a different version that's within reach you should use that channel instead.

Note: At this time we do not believe there are any in cluster or CLI UX changes, this is currently mostly a channel management endevour. However since clusters auto discover reachable channels it will result in in cluster changes in both the Admin Web Console and CLI (`oc adm update channel` command).

Note: OCPSTRAT-1569 proposes expanding skew limits to any 4.N to 4.N+2 and 4.N to 4.N+3 pending QE and CI tests being in place. Once that's been implemented channel promotion would change as well.

Proposal: https://docs.google.com/document/d/1e8fHcb5tW2hRrQwbFliipnzx5bB6C_pdFBnZFO5ZfIg/edit?tab=t.0#heading=h.7pgvbgum96wc