diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml
index fae1e57e5..27f14a1ed 100644
--- a/.github/release-drafter.yml
+++ b/.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
diff --git a/RELEASE.md b/RELEASE.md
index 869d6773a..eedfc7c16 100644
--- a/RELEASE.md
+++ b/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
diff --git a/development.md b/development.md
index c5dccda1a..e40884f9f 100644
--- a/development.md
+++ b/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.