1# Versioning and Branching in controller-runtime
2
3We follow the [common KubeBuilder versioning guidelines][guidelines], and
4use the corresponding tooling.
5
6For the purposes of the aforementioned guidelines, controller-runtime
7counts as a "library project", but otherwise follows the guidelines
8exactly.
9
10[guidelines]: https://sigs.k8s.io/kubebuilder-release-tools/VERSIONING.md
11
12## Compatibility and Release Support
13
14For release branches, we generally tend to support backporting one (1)
15major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back
16further if the need arises and is very pressing (e.g. security updates).
17
18### Dependency Support
19
20Note the [guidelines on dependency versions][dep-versions]. Particularly:
21
22- We **DO** guarantee Kubernetes REST API compatibility -- if a given
23 version of controller-runtime stops working with what should be
24 a supported version of Kubernetes, this is almost certainly a bug.
25
26- We **DO NOT** guarantee any particular compatibility matrix between
27 kubernetes library dependencies (client-go, apimachinery, etc); Such
28 compatibility is infeasible due to the way those libraries are versioned.
29
30[dep-versions]: https://sigs.k8s.io/kubebuilder-release-tools/VERSIONING.md#kubernetes-version-compatibility
View as plain text