Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

OLM should provide a way to specify when an Operator is going out of support and needs to be removed from the catalog. This should improve catalogs performance and avoid the user installing unsupported software.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

The user should not be able to install deprecated operators or operator versions that are out of support. 

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

<enter general Feature acceptance here>

1. If an operator is unsupported and does not appear in the latest documentation of OCP (after deprecation note in the release notes), it should not be available for installation in that version of OCP.
2. If a specific operator version is out of support for this release of OCP, it should not be available for installation for that version of OCP.
3. This page should the source of truth for operators life cycle: https://access.redhat.com/support/policy/updates/openshift_operators 

Additional considerations:

• There are performance issues with the catalogs today. Removing unsupported versions should reduce catalogs size and improve performance.
• OLM should provide a way to specify end of life or deprecation of an operator. Next step is to enforce this requirement in the pipelines and ensure all the Operators and Extensions built via OLM comply with this requirement.
• This feature applies to OLM v1 only.
• TBD: how far back to we to go to clean up existing catalogs? 

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

<your text here>

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Our customers should know about this mechanism put in place, once it is implemented, to ensure that the life cycle is going to be enforced stricter.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

The documentation should be mostly for operator and extension owners shipping their operators with OLM.

There should be a release note for the end user in the OCP documentation about the change, once OLM has implement the deprecation workflow. 

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>