Create a versioning policy

[chrisseto]

We need to define, document, and utilize a versioning and support policy for helm, the operator, redpanda, and Kubernetes versions. We'll also need to figure out the best way to announce deprecations / release notes / etc (cc @JakeSCahill as I bet you have some ideas)

Straw man proposal:

Support Policies

Support policy here means "What versions of our products will we accept bugs and/or feature requests for?"

Helm / Operator

The two most recently released minor versions will be supported and receive patch fixes.
IE 8.0.x and 7.10.x or 8.1.x and 8.0.x

Redpanda

I'm guessing this already exists?

Kubernetes

We run tests against and support the same version window as the most aggressive cloud provider.
Non-tested and non-supported versions may work just fine but we won't do anything to try to support them if there are breakages.

Version Policies

Version policy here means "What version matrix and backwards compatibility do we test and guarantee will work?"

Helm / Operator

All minor versions will be backwards compatible by at least 1 version. The suggested upgrade path will be to increment the minor version by 1 until you're up to date with the most recent.

Redpanda

I'm guessing this already exists as well?

Kubernetes

Same deal as the support policy.

These are strawpeople, tear them to shreds and please inform me of any prior art on the matter.

Tasks

Beta Give feedback

1. Create a Kubernetes Versioning/Support Policy #1146
   +0

JIRA Link: K8S-119

[chrisseto]

We'll probably want to break out a sub ticket for each policy that needs to be discussed as this starts to get more eyes.

Some notes on K8s versions:

• Testing against multiple K8s Versions / Flavors is prohibitively expensive and time consuming.
  • Maybe it's worth running against a broad range once a week/month?
• In theory, we don't leverage too many specific features. If there are k8s version linters that we could rely on to catch deprecations and the like we could probably get away without running full E2E tests.
• As noted above, we shouldn't care too much about versions / flavors of K8s (Except for openshift, it's known to be special). I'd prefer that we wait to hear back from users about any issues with specific versions or flavors given the high investment and upkeep of these types of tests.