## Summary

The plan is to reduce the number of OpenShift Pipelines version we
support at a given time while augmenting the number of OpenShift
version we support them in.

Supporting Materials:
* [Enhance Support Policy of OpenShift Pipelines](./enhance-support-policy.md)
* [OCP 4.y lifecycles](https://docs.google.com/document/d/1exNNJPdwCH3F5eEKaLVBcrj_qAHfJ3PlfnquP0-6TxM/edit#heading=h.539ohzh6t1k6)
* [Proposal for Pipelines &
GitOps](https://docs.google.com/spreadsheets/d/1Tn6BHNBJnEaTBRm22U0KrNCR_Zwu_qBn-IR-xFEa4Os/edit#gid=1430910332)

## Motivation

OpenShift Pipelines versions are currently only shipped and supported
for a small set of OpenShift version (n-1, n, n+1). OpenShift support
can be very long (especially for EUS version), which makes us having
to support a lot of version at the same time. Adding to this support
exception that we may give to customers, it can become a burden for
maintainance, and a lot of bugfix version to release.

For example, today (2023, 31st of July), we are *technically*
supporting the following:
- 1.8.x on 4.10 (EUS)
- 1.9.x on >= 4.10
- 1.10.x
- 1.11.x

In addition, it has no real technological reason for not supporting
multiple version. Tekton supports a relatively wide range of k8s
version, and so can OpenShift Pipelines.

Enabling customers to get the latest of feature from Tekton in their
supported cluster is a win-win situation : customers can use the
latest, and we can ship the latest (fixes, …) to our customers.

## Proposal

### Support only the last 2 releases

The proposal is to only support the last 2 releases. As of today, this
would mean supporting 1.11 and 1.10.

In addition, as soon as release N is released, release N-1 becomes in
maintenance mode, aka gets only critical bugfixes and security
fixes. Quick note on this, it would also get any bugfix release if
upstream components tracked in that release do a bugfix release as
well.

The idea of the proposal is to make it more appealing to get the
latest release. The only challenge can be the
`MIN_KUBERNETES_VERSION`, as discussed below.

### Support down to `MIN_KUBERNETES_VERSION`

Each version we release is supported on **any** OpenShift version that
satisfy the following:

- OpenShift version is still supported.
- The pipeline `MIN_KUBERNETES_VERSION` is compatible with the
kubernetes version of OpenShift.

In a gist this would mean, today, that:

- 1.11 (`MIN_KUBERNETES_VERSION` = 1.24) is supported on >= 4.11
- 1.10 (`MIN_KUBERNETES_VERSION` = 1.23) is supported on >= 4.10

As of today, no OpenShift version below 4.10 is supported, so we could
support only 1.10 and 1.11. In the case of an OpenShift version is
still supported but the `MIN_KUBERNETES_VERSION` is lower than any of
the 2 most recent OpenShift Pipeline's release, we would have to
support that one (in maintenance/security mode) until the given
OpenShift release is not supported anymore, but only on that given
OpenShift version.

For example, when we release 1.12 (`MIN_KUBERNETES_VERSION` = 1.24),
we will need to still support 1.10 *on* 4.10 (not necessarily on 4.11
or higher).