Epic Goal

Contrary to SemVer expectations, 4.22 to 5.0 updates are not expected to include backward incompatible changes that require clusters to be re-installed. In order to support those updates, by the time 5.0 opens, the graph-data repository's release-*.sh scripting needs to be updated to understand that the minor release before 5.0 is 4.22, and that 5.0 is maybe not going to be EUS, and whatever else it is that folks think needs to go into managing channel naming and membership now that OCP 5 may become a thing.

Why is this important?

The channels help cluster administrators navigate multi-hop updates, e.g. moving from the EUS 4.18.z through 4.19.z' to the EUS 4.20.z smoothly by setting a *-4.20 channel while on 4.18.z, to avoid ending up on a 4.19.z that's too new to have a newer 4.20.z in that channel yet. We don't provide this between non-EUS releases, e.g. fast-4.19 includes 4.18.z and 4.19.z, but does not include 4.17.z, because we do not currently invest the time in 4.17.z releases that it would take to reliably warn cluster admins about coming 4.19 changes they might need to prepare for (OTA-1391?). This ticket is about pinning down what we plan to invest in now that OCP 5 may become a thing, and then updating the graph-data tooling to reflect those decisions.

Scenarios

There will be *-5.0 channels, starting with candidate-5.0 once we cut our first Engineering Candidate. I'm not sure yet when that will happen. But by the time each channel is created, we'll need decisions on (and hopefully script automation for) our policy for what the channel names should be and what should go into them. Minimum disruption would be something like:

• 5.0 will not be EUS, so no eus-5.0 channel.
• 5.0 will not support larger skew than the usual 4.odd release, so candidate-5.0, fast-5.0, and stable-5.0 channels will only ever include 4.22 and 5.0 releases.
• The usual post-GA delay before 4.22 releases are added to stable-5.0.

Dependencies

No dependencies outside OTA. Subin and Scott may have opinions on what the policies should be.

Contributing Teams

• Development - OTA
• Documentation - OTA
• QE - OTA
• PX - OTA
• Others - not required

Acceptance Criteria

The graph-data repository's release-*.sh scripting understand 5.0 policies, and OTA can run the scripts at the relevant lifecyle event without having to check back in for policy confirmation.

Drawbacks or Risk

Not developing a policy would leave cluster admins unable to update from 4 to 5.

Done - Checklist

• CI Testing - Tests are merged and completing successfully
• Documentation - Docs about the new channels checked for accuracy in the run up to 5.0 GA. Probably needs an audit Spike.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Other