docs: document branching strategy

Author: justinsb

docs/book/src/developers/releasing.md

@@ -7,6 +7,24 @@
       - Open a PR in https://github.com/kubernetes/test-infra to change this [line](https://github.com/kubernetes/test-infra/blob/25db54eb9d52e08c16b3601726d8f154f8741025/config/prow/plugins.yaml#L344)
         - Example PR: https://github.com/kubernetes/test-infra/pull/16827
 
+
+## Branching strategy
+
+Cluster-API Provider GCP release numbers follow the spirit of semver.
+
+The major and minor versions mirror the version of Cluster-API.  Thus CAPG 1.11.x releases will use CAPI versions 1.11
+The patch version is incremented for each release.  Thus the first release of CAPG using CAPI 1.11 will 1.11.0, the second will be 1.11.1, etc
+
+We maintain release branches to faciliate backporting fixes.  These are named `release-<major>.<minor>`.  Patch releases are tagged from the corresponding release branch.
+
+Feature development happens on the `main` branch, and is used to release nightlies.  While we aim to keep the `main` branch healthy, it is intended for development and testing, and should not be used in production.
+
+As such, we will aim to keep the main branch up to date with the latest versions of all dependencies (go toolchain, CAPI, other go module dependencies).
+
+Release branches lock to a particular minor version of CAPI, but will update other dependencies on these branches while they are supported.
+Currently we maintain only one release branch (and the `main` branch).  Once a branch is no longer supported there will be no new releases
+of the corresponding minor, including no further security fixes.
+
 ## Prepare branch, tag and release notes
 
  - Update the file `metadata.yaml` if is a major or minor release