## Goals

1. Content that is only meant for 4.x should only show up in 4.x
2. Teams have at least one supported update path across subsequent indexes / clusters
3. Teams have the ability to mark versions as deprecated / uninstallable

## Challenges

1. Pub understand 4.x to mean =4.x when it should understand it to be 4.x+ today. The refresher job is the only thing today filling that gap of pulling content forward.
2. Index modifications done by EXD / RCM are often not persisted because the refresher job only knows about bundles. Current examples:
- removing a bundle from 4.6 that is also in 4.5 will not persist
- overwriting a bundle only in 4.6 that is also in 4.5 will not persist
- overwriting a bundle in 4.5 will not overwrite that bundle in 4.6 (**GAP**)
- changes to the update graph (default channel etc.) cannot persist because bundles are the only source of truth
3. If a team realizes in stage testing that a version works in 4.6 but not 4.7, should the team rebuild their bundle with the label "=v4.6" or should they mark the version as deprecated in 4.7?
- the former means rebuilding and restarting the QE process
- the latter means the deprecation job needs to run more than once in order to ensure it picks up deprecations that are affected ahead of time. (**Note**: this is not possible today since deprecating a bundle that is not in an index raises an error)

## Example Graphs

### Example 1 (One channel per OCP version)

Today, because the refresher job pulls all content forward. Certain teams have the following update graphs per index.

4.5 Index

4.5-ch:
    CL-4.5-timestamp skipRange <= 4.5

4.6 Index

4.5-ch:
    CL-4.5-timestamp skipRange <= 4.5
4.6-ch:
    CL-4.6-timestamp skipRange <= 4.6 (includes 4.5)

4.7 Index

4.5-ch:
    CL-4.5-timestamp skipRange <= 4.5
4.6-ch:
    CL-4.6-timestamp skipRange <= 4.6 (includes 4.5)
4.7-ch:
    CL-4.7-timestamp skipRange <= 4.7 (includes 4.5 and 4.6)

The above has the following impact:

1. Content unsupported on 4.x is present on 4.x for install
- Deprecation of older versions is not relevant for this team as they only keep track of a single version per index
- if they want to mark the head of a channel as deprecated, if the builds are too frequent, manually creating PRs to mark the specific SHAs of the new channel head as deprecated is not possible
- would need the ability to mark a channel as deprecated or removed
2. To update after cluster upgrade, teams must manually update their subscription to change channels

#### Desired State

4.5 Index

stable:
    CL-4.5-timestamp skipRange <= 4.5

4.6 Index

stable:
    CL-4.6-timestamp skipRange <= 4.6 (includes 4.5)

4.7 Index

stable:
    CL-4.7-timestamp skipRange <= 4.7 (includes 4.5 and 4.6)

which has the following impact:

1. Only supported content is present in the index
2. Updates after cluster upgrade require no manual intervention
3. **Refresher Job is not needed in this case**
- Deprecation is not needed as there is only ever one version per index

#### How does this team get there?

1. The refresher job stops pulling content forward for this team.
2. The indexes are modified to remove unsupported channels (NEEDS TOOLING)
3. The channels are renamed accross indexes (NEEDS TOOLING)

Alternatively

1. The team creates a new channel called stable where they will release all versions. Bundles should use the new versioning scheme to pin to a specific index.
2. The refresher job pulls content forward but this content is overwritten at add time because bundles are only using skipRange
3. The old channels are removed (NEEDS TOOLING) and this change is persisted such that the refresher job does not re-create these manually deleted channels.