Cherry-picking changes back to previous branches ¶
Background ¶
Anyone can propose a cherry-pick - you do not need to be the original author.
We typically have multiple release branches "open" at once - ideally one that is
a stable release branch ("GA"), one that is a beta, and one that is an alpha.
Sometimes the alpha branch will be the master
branch.
Broad guidelines for acceptance of a cherry-pick:
- Once a version is beta or GA, we typically won't cherry-pick new features back to it.
- We typically will cherry-pick security-fixes and regression-fixes into the GA branch (and the alpha & beta branches).
- We may cherry-pick bug-fixes into the stable branch if the bug is sufficiently severe and outweighs the risk of introducing new regressions.
- Generally we are more accepting of cherry-picks to the beta branch (bug-fixes generally accepted), and very accepting to the alpha branch (features and bug-fixes generally accepted). As a beta is maturing to GA, and the alpha is maturing into a beta, we will become more risk-averse on the cherry-picks, so that the branches can stabilize.
We are currently tracking cherry-picks to the various branches in a spreadsheet
Process ¶
The kubernetes repo has a script for cherry-picking and you can download the raw form using something like:
wget -O /usr/local/bin/cherry_pick_pull.sh https://raw.githubusercontent.com/kubernetes/kubernetes/master/hack/cherry_pick_pull.sh
chmod +x /usr/local/bin/cherry_pick_pull.sh
(You may also have ~/bin
on your PATH
, which is probably a better location than /usr/local/bin
)
Then you can propose a cherry pick of PR using something like:
UPSTREAM_REMOTE=origin \
FORK_REMOTE=${USER} \
GITHUB_USER=${USER} \
cherry_pick_pull.sh origin/release-1.15 12345
Tip: If you find yourself doing this often, you may want to create a wrapper script
that sets UPSTREAM_REMOTE
, FORK_REMOTE
and GITHUB_USER
to your values.