Update our track strategy for the Kubeflow 1.9 release

[ca-scribner]

Context

In recent releases we have not promoted charms to latest/stable in the charm repositories, leading to confusion. This was in part because we discussed removing the latest track entirely from our charms, instead opting to update our default track to whatever is the most recent release (say 1.8).

We should define what we want (do we use latest at all? do we promote to latest/stable? etc) before the 1.9 release

What needs to get done

1. define and document our track strategy for charms

Definition of Done

1. track strategy for charms is defined and documented

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5652.

This message was autogenerated

[orfeas-k]

Discussed in https://docs.google.com/document/d/1WYWf8BEbB_nPasVwBWaDhhmnu461hZdFNVSAA4an1-s/edit#heading=h.lfxtpxci0bkl

[orfeas-k]

Context

(a) What should we do with the latest/stable track? Where should it point to and if it should even exist? (b) What would be the default track when deploying a charm?

Options

For (a), options are:

1. latest/stable → /stable - should we do this just for the bundle or for charms as well?
2. get rid of latest/stable - means we will have to update the default one
3. latest/stable → latest/edge For (b), options are:
4. <version>/stable is default
5. keep latest/stable as default
6. latest/edge is default

Conclusions:

1. Hide latest/stable in both bundle and charms
2. Change the default track to be a version
3. Expect latest/candidate and latest/beta only for testing (SolQA), but we do NOT expect anyone to use it in our docs
4. Let’s deprecate/remove/hide the 1.7 (and previous unmaintained) tracks for both bundle and corresponding charms