From 45aaa161a1ef725f0345d230deda0e899f954a23 Mon Sep 17 00:00:00 2001 From: Vince Prignano Date: Mon, 30 Nov 2020 10:12:09 -0800 Subject: [PATCH] :book: Relax our backporting guidelines and policies This change relaxes and defines a bit more what can be backported and how. After this change is merged, we'll allow both bug fixes and minor (non-breaking) features to be backported if at least one or more maintainers approves the cherry pick. With these changes we aim to be more welcoming of changes to the current stable branch instead of stopping the world until the next releases. The only caveat is that backports that I'd like to highlight is that backporting is an expensive operation. More often that not, a cherry-picked commit requires another full review because changes are usually not compatible. Going forward, we won't allow PRs to target a release branch directly, we'll always require changes to go in the main branch first, and only after they've been merged, to backport them. Signed-off-by: Vince Prignano --- CONTRIBUTING.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4c040aed4fde..f2cb6d9351b7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -145,10 +145,18 @@ process. ## Backporting a Patch -Cluster API maintains older versions through `release-X.Y` branches. We accept backports of bug fixes to the most recent -release branch. For example, if the most recent branch is `release-0.2`, and the `master` branch is under active -development for v0.3.0, a bug fix that merged to `master` that also affects `v0.2.x` may be considered for backporting -to `release-0.2`. We generally do not accept PRs against older release branches. +Cluster API maintains older versions through `release-X.Y` branches. +We accept backports of bug fixes and non breaking features to the most recent release branch. +Backports MUST not be breaking for both API and behavioral changes. +We generally do not accept PRs against older release branches. + +As an example: + + Let's assume that the most recent release branch is `release-0.3` + and the main branch is under active development for the next release. + A pull request that has been merged in the main branch can be backported to the `release-0.3` + if at least one maintainer approves the cherry pick, or asks the PR's author to backport. + ## Features and bugs