Outcome Overview

To reduce the amount of change as part of an update to OpenShift 5.0, customers should be able to transition from OpenShift 4.22 to OpenShift 5.0 without being required to update their installed operators.

Success Criteria

All OLM-managed Red Hat-provided operators need to ensure that their latest version that was released on 4.22 prio to 5.0 GA is also supported on OpenShift 5.0. The exception here is operators currently in DP/TP and strictly version-aligned operators like ODF and CNV, which require a strict coupling between their release and the underlying cluster version due to low-level kernel/OS dependencies.

Operators do not have to support all their currently (as of 5.0 GA) supported releases on OpenShift 5, only the latest one they cover OpenShift 4.22 with.

Hypothetical example: Your operator v1 was released on Openshift 4.21, but also supported 4.20 and 4.19. Your operator v2 was first released on 4.22, but also supported 4.21 and 4.19. Your operator v3 is first released on OCP 5.0, but also supports 4.21 and 4.20. The requirement is that your operation v2 also supports OCP 5.0. v1 does not to have to support it.

Expected Results

A customer who is up to date with their installed operators on OpenShift 4.22 does not need to factor in an additional update of any of their operators prior to or after updating to OpenShift 5.0.

All Red Hat provided operators have at least one version that supports OpenShift 5.0 at launch.