Investigate how we deal with breaking changes in cluster charts

[yulianedyalkova]

Currently we're planning to release a few breaking changes that we want to push into v30. But if we want to backport something into the old releases, we need to make sure we have a clear way of doing so without accidentally pulling in breaking changes into old releases.

Ideas:

• Support multiple branches per release so that we can easily backport features to them
• Make changes in-code that ensure that a feature get enabled only for specific Kubernetes releases
• What else (please explore other best practices)

Acceptance criteria:

• Evaluate different options and document clearly their downsides / risks / benefit before making a decision

[njuettner]

Added a doc for our conversation about this: https://docs.google.com/document/d/16cATtFuIOnIADcpPcjQMrMPe2sYPleV3xSxY53X-spc

[Gacko]

I left some comments on the document. In general I'd vote for option 2.

[AverageMarcus]

None of the options feel great unfortunately 😞

I'm having a hard time deciding on the least bad but I think I also agree with option 2 - mainly because it minimally effect the current way of doing things and can be relatively easily reverted if we later come up with a better solution.