Epic Goal

ACM and MCE would like to join the Tier1 club. This entails:

• Release strategy - Multiple minor versions supported in parallel
• Versioning - Semantic versioning
• OCP coverage - Different operator versions support different OCP releases. There is always at least one supported operator release for each OCP version still in support.
• Support Length - For each OCP version there is an aligned operator release that has the same support lifecycle. (Additional shorter-lived releases are optionally possible.)
• EUS-to-EUS - For each EUS-to-EUS upgrade path the layered product offers an update path or supports both EUS releases in one product version
• Release cadence - The aligned release within 1 month after OCP minor release GA, further releases are independent of OCP dates
• Release delivery - OLM channels are named 'stable', optionally 'fast' and 'candidate' for the aligned version, optionally one OLM release channels per minor-version of your product
• Lifecycle Phases - "Full Support" and "Maintenance" and they align with the aligned OCP release

Submariner, VolSync, Gatekeeper would like to join the Tier2 club. This entails the above but with a few small differences:

• Support Length - Custom length, generally shorter support cycle than OCP
• Release cadence - Releases independently of OCP minor releases
• Release delivery - One OLM release channels per minor-version and a ‘stable’ channel containing the preferred minor version for each OCP version
• Lifecycle Phases - “Full Support” and “Maintenance”

Global Hub would like to join the Tier3 club. This has quite a few differences:

• Release strategy - A single rolling release (minor or major)
• Versioning - Semantic versioning
• OCP coverage - A single latest stable version is supported on all non-EOL OCP releases
• Support Length - Determined by the release cadence
• EUS-to-EUS - Does not support EUS-to-EUS upgrades
• Release cadence - Releases independently of OCP minor releases
• Release delivery - OLM channels are named ‘stable’ and optionally  ‘fast’ and ‘candidate’
• Lifecycle Phases - n/a

See preso:

https://docs.google.com/presentation/d/1GD29PRJwYckO6zw73fw3eVUu1hmsdMYhNuKxx4uX7SM/edit#slide=id.g1ccea862d8c_46_0

Why is this important?

• Current Situation
  Customers are encouraged to enhance the value of their OpenShift clusters by installing layered products. All layered products have their own lifecycle.
• Customer Challenge
  Customers perceive OpenShift and its layered products as one offering. They struggle with the fact that each of those operators have their own lifecycle. Some would ideally not touch an EUS cluster until the next EUS release. Starting with 4.12 every even numbered OCP release will be supported 24 months. This will amplify the challenge.
• Ideal outcome
  Every layered uses 1 out of 3 predefined product lifecycle models ensuring uniformity and predictability among updates.

Scenarios

1. ACM & MCE 'odd' releases align with OCP 'even' releases:
   1. OCP 'even' releases are supported for 2 full years (or in the future, potentially longer).
   2. ACM & MCE 'odd' releases need to extend their software lifecycle length to cover the full length that an OCP 'even' release has Full and Maintenance support

Acceptance Criteria

Updates to the ACM and MCE software lifecycle topics

ACM: https://access.redhat.com/support/policy/updates/advanced-cluster-management

MCE: https://access.redhat.com/support/policy/updates/openshift#mce

Including the Tier2 lifecycle definitions for: Gatekeeper, VolSync, Submariner, klusterlet, OADP

And Tier3 lifecycle definition for: Multicluster global hub operator

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. https://docs.google.com/spreadsheets/d/1nkUMRuzRjvYxIi4wKb4Br7BDVe_AqvSyCJWxrfE4AT8/edit#gid=1585218304
2.  

Open questions:

1. ...

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>