Document Kubernetes API policy (#1642)

Signed-off-by: Jan Schlicht <[email protected]>

.github/release-drafter.yml

@@ -20,6 +20,10 @@ template: |
 
   $CHANGES
 
+  ## Supported Kubernetes Versions
+
+  This release of KUDO is using the Kubernetes API 1.19 and is compatible with Kubernetes versions 1.17, 1.18, and 1.19.
+
   ## Contributors
 
   $CONTRIBUTORS

RELEASE.md

@@ -69,7 +69,7 @@ The token must grant full access to: `repo`, `write:packages`, `read:packages`.
 
 1. Tag the kudo repo with expected release `git tag -a v0.2.0 -m "v0.2.0"` and push the tag `git push --tags`.
 1. Invoke goreleaser `goreleaser --rm-dist`.
-1. Update the GH release with release highlights. There is a draft that contains categorized changes since the last release. It provides categories for highlights, breaking changes, and contributors which should be added the gorelease release notes. The changelog from the draft log is ignored. After the contents are copied, the draft can be deleted.
+1. Update the GH release with release highlights and supported Kubernetes versions. There is a draft that contains categorized changes since the last release. It provides categories for highlights, breaking changes, and contributors which should be added the gorelease release notes. The changelog from the draft log is ignored. After the contents are copied, the draft can be deleted.
 1. Merge the [branch](#documentation) of the [`kudo.dev`](https://github.com/kudobuilder/kudo.dev) repo dedicated to current release
    into `main`, following the regular GitHub pull request process.
 1. Immediately after that, create a `post-v0.2.0` branch for documentation for a *future* release

development.md

@@ -31,6 +31,11 @@ The follow are a list of tools needed or useful in order to build, run, test and
 * [ngrok](https://ngrok.com/) - This is currently needed for full debugging. We are looking at alternatives. It does require signing up for this service.
 * [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) - Binaries for `kube-apiserver` and `etcd` from kubebuilder are used for integration testing.
 
+## Supported Kubernetes versions
+
+Use of Kubernetes APIs is limited to APIs supported by the current version of Kubernetes' `kube-apiserver` and two minor versions older at the time of a KUDO release. This is similar to the allowed version skew of `kubelet` and `kube-apiserver` following [Kubernetes' version skew policy](https://kubernetes.io/docs/setup/release/version-skew-policy/). E.g., for a version of KUDO released while Kubernetes 1.18 is current, only APIs that are supported in Kubernetes 1.16, 1.17 and 1.18 can be used.
+Functionality using APIs that don't conform to this rule should be placed behind a feature gate.
+
 ## Running Locally
 
 These details will show using kind as a local kubernetes cluster.  These instructions should work with minikube as well.