-
Story
-
Resolution: Done
-
Undefined
-
None
-
None
Proposal:
when configuring the upgrade graph for v4.y.z, always enable a direct:
v4.y-1.k (where k is the latest released) -> v4.y.z
currently in general we have only:
v4.y-1.k -> v4.y.0 -> v4.y.1 ... -> v4.y.z
Benefits:
- a short upgrade path for customers
- the customer will not risk to re-encounter on v4.y.0 bugs and security issues he already got a fix for on v4.y-1.k
Risks:
- the impact on the test matrix
- depends on
-
CNV-49574 [QE] Ensure we extended the release checklist to cover upgrading from what's currently on prod on prev OCP minor
- New
-
CNV-49576 [QE] Ensure we extended the release checklist to cover upgrading to what's currently on prod on next OCP minor
- New
- is duplicated by
-
CNV-48373 [RFE] Allow Openshift Virtualization upgrade skipping intermediate versions
- Closed
- is related to
-
CNV-48449 Fast channel for z-streams (weekly)
- Backlog
-
CNV-39574 alert SSPCommonTemplatesModificationReverted fire's on healthy cluster
- Closed
- split to
-
CNV-49851 [merge & enable additional edges ] Always configure also a direct upgrade path between the latest z stream on the previous OCP minor to the next z stream
- New
- mentioned on