From 8530d61b889cd783c2e21b9ddded5714a3c63c5d Mon Sep 17 00:00:00 2001 From: justinsb Date: Wed, 29 Jan 2025 08:15:37 -0500 Subject: [PATCH] docs: document our branching / versioning process We want to be more systematic about our branching / versioning. Document the process we were (trying to) follow. We can also automate some of the toil here. --- .../branching-and-versioning.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 docs/project-management/branching-and-versioning.md diff --git a/docs/project-management/branching-and-versioning.md b/docs/project-management/branching-and-versioning.md new file mode 100644 index 00000000..cfebde58 --- /dev/null +++ b/docs/project-management/branching-and-versioning.md @@ -0,0 +1,32 @@ +# Branching and versioning strategy + +## Versioning + +kubebuilder-declarative-pattern is a library, that works with controller-runtime and kubernetes. + +We follow semantic versioning, similar to other tooling in the kubernetes ecosystem. + +Because both controller-runtime and client-go introduce changes that require code changes, we follow their versioning. +Specifically we align with the controller-runtime version, which itself aligns with kubernetes versioning. + +Thus: + +| kdp version | controller-runtime version | client-go version | +|---|---|---| +| v0.20 | v0.20 | v0.32 | +| v0.19 | v0.19 | v0.31 | +| v0.18 | v0.18 | v0.30 | +| ... | ... | ... | +| v0.x | v0.x | v0.x+12 | + +If we need to release multiple versions of kdp for a single version of controller-runtime (for example if we want to fix a bug), +we use patch versions for that. +We want to avoid breaking changes, and we will only make breaking changes on minor version bumps (as far as possible). + +## Branches + +We maintain a `release-0.x` branch for the kdp major version `0.x`. Patch versions are cherry-picked to the branch and released. + +We cut the release branch with the beta release (i.e. we create `release-1.100` when we tag `1.100.0-beta.1`). + +Before beta releases, the master branch is for the next minor version. If we tag a version, it would be (for example) `1.101.0-alpha.1` (and then `1.101.0-alpha.2` etc), assuming the most recent release branch was `1.100`