Add Standard document for version policy regarding k8s updates

[ajfriesen]

Here is my first draft regarding the version policy.

[joshmue]

Nice!

Right now, the record primarily concerns the speed of picking up new Kubernetes releases.

There are also a few other relevant topics, which may end up (a) not standardized, (b) in this record or (c) as a series of distinct records:

Support of non-current Kubernetes versions / pace of EOL-ing

What older releases is the provider required to support? All non-current "Minor" releases that are still supported upstream? Maybe more or less? Are patch releases treated differently?

Responsibilities provider vs. customer

Does the provider prepare version upgrades, but the customer triggers the upgrade on their schedule? Perhaps use another model for patch releases?

[garloff]

Document looks really good to me.
A few minor suggestions:
1.) Please add the DCO (Signed-Off-By) to your commit message, otherwise we can not merge the PR. git --amend -s and then force push (--force-with-lease) to the branch.
2.) A small section that says that there how long minor versions stay supported is subject to another Standard document. (The comment from Joshua is a good one, of course!)

[garloff]

@joshmue:

• EOL'ing: I guess I would require providers to support minor versions at least as long as they are supported upstream. This thus means 14 months after 1.x.0 has been released acc. to current policies.) More is allowed, but customers probably should receive a warning.
  But let's take this one into the next team meeting.

• Upgrade responsibility:

  • For self-managed clusters, the provider responsibility ends with registering the tested node image ...
  • For provider-managed clusters, I would expect customers having a variety of wishes:
    [ ] The ability to initiate rolling upgrades to new patches and to new minor versions manually (API call / gitops reconciliation)
    [ ] The ability to get notifications when clusters run outdated patchlevels or EOL'ed minor versions.
    [ ] The ability to opt-in for provider initiated patch-level upgrades soon after a new patch level is approved by the provider
    [ ] The ability to opt-in for provider-initiated minor version upgrade. As this has a real risk to break things, I would expect customers to only want this for non-productive clusters ...

  This is also to be discussed in the next team meeting.

[ajfriesen]

We discussed that we want to create different ADR for the following topics:

• How long do scs compliant providers need to support versions
• Who does the upgrade of the cluster (user of that cluster or the provider or some mixed mode?)

[garloff]

/lgtm

[garloff]

Looks still good.