oadp channels

* STABLE
* when a y channel

STABLE = 1.0.1 1.0.2 1.03
then intro 1.1

then stable becomes:
STABLE = 1.0.1 1.0.2 1.0.3 + 1.1
STABLE 1.1 = STABLE

Kevin said cannot have this
stable: 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1 -> 1.2.0
stable-1.1: 1.1.0->1.1.z
stable(after 1.2): 1.0.0 -> 1.0.z -> 1.1.0 -> 1.1.1 -> 1.2.0

    stable:  1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1 -> 1.2.0 -> 1.2.1
stable-1.0:  1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.0.4 -> 1.0.5 -> 1.0.6
stable-1.1:  1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1 -> 1.1.2
stable-1.2:  1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1 -> 1.2.0 -> 1.2.1

>
Kevin Rizza
31 minutes ago
you can definitely "cut up" the graph to look the way you want

Kevin Rizza
31 minutes ago
what you can't do is just have a different graph for different bundles depending on the channel

you can't exclude a bundle from some channels and not others if you want to have a channel with every bundle installable

<wes>
Proposal:
Channel = "stable"
(today) stable: 1.1.0
(proposed) stable: 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1

Channel = "stable-1.1"
(today) = 1.1.0 -> 1.1.1
(proposed) = 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1

Propose moving previously released versions to stable to fix Dell and deprecate stable in the long term.

A perfect solution would be to have every version past and future added to stable and have the skip_versions handle the install to the latest version, customers could manually install *any* version. This is not possible w/ olm.
This is not possible because of timing. For example 1.0.4 will release after 1.1.0, olm would expect an upgrade from 1.1.0 to 1.0.4 to work.

Deprecate the OADP "stable" channel. Although we had good intentions w/ the stable channel the inability for customers to continue on a z stream after a y release makes the stable path inconsistent. Manual intervention to upgrade to a y release given there are crd and api changes is more prudent than allowing customers to automatically upgrade from 1.0.3 -> 1.1.

Deprecation of the stable channel should be well documented, well communicated and have a notice of 12 months.

Only have y channels in the future.
</wes>

(proposed) stable: 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.1.0 -> 1.1.1 -> 1.2.0 -> 1.2.1