Feature Overview (aka. Goal Summary)  

• Note: This feature is aimed to track the progress of Phase 1 MVP scope for the OLM 1.0
  • i.e., "IsMVP: YES" in the table of Functional Requirements.

• OLM replaces the older version of the extensions with a newer version atomically after the target version is defined by the administrative personas.

Goals (aka. expected user outcomes)

• All versions of a package within the channel of a catalog should be allowed for selection by the user as the desired target version.
• OLM replaces the older version of the extensions with a newer version atomically.

Requirements (aka. Acceptance Criteria):

Use Cases

• OLM 1.0 users can set a target version manually so that OLM replaces the older version of the extensions with a newer version atomically.
  • No update path concept in this release --> No auto-update.

Definition of Done / Acceptance criteria

• All use cases above are implemented and meet the requirements (requirements for MVP takes priority).
• Although not part of this feature, the design should take how F23 (Opt-in to fallback/rollback) can be implemented into consideration.

Background, and strategic fit

This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

Documentation Considerations

• The way “OLM 1.0 users can set a  target version” needs to be documented (in the context of “Administrator tasks”).