Feature Release Process¶
This document describes the process for creating a major or minor feature release of Cilium.
On Freeze date¶
Fork a new release branch from master:
git checkout master; git pull origin master git checkout -b v1.2 git push
Protect the branch using the GitHub UI to disallow direct push and require merging via PRs with proper reviews. Direct link
Replace the contents of the
CODEOWNERSfile with the following to reduce code reviews to essential approvals:
* @cilium/janitors api/ @cilium/api pkg/apisocket/ @cilium/api pkg/monitor/payload @cilium/api pkg/policy/api/ @cilium/api pkg/proxy/accesslog @cilium/api
Create a new project named “X.Y.Z” to automatically track the backports for that particular release. Direct Link:
.github/cilium-actions.ymlfrom the previous release
vX.Y-1change the contents to be relevant for the release
vX.Yand set the
project:to be the generated link created by the previous step. The link should be something like:
Commit changes, open a pull request against the new
v1.2branch, and get the pull request merged
git checkout -b pr/prepare-v1.2 git add [...] git commit git push
Create the following GitHub labels:
Checkout to master and update the
.github/cilium-actions.ymlto have all the necessary configurations for the backport of the new
git checkout -b pr/master-cilium-actions-update origin/master # modify .github/cilium-actions.yml git add .github/cilium-actions.yml git commit git push
Continue with the next step only after the previous steps are merged into master.
Mark all open PRs with
needs-backport/x.ythat have the milestone
Change the VERSION file to contain the next
rcversion. For example, if we are branching v1.2 and still in the RC phase we need to change the VERSION file to contain the
Set the branch as “Active” and the “Privacy Level” to “Private” in the readthedocs Admin page. (Replace
v1.2with the right branch)
Since this is the first release being made from a new branch, please follow the Generic Release Process to release
Alert in the testing channel that a new jenkins job needs to be created for this new branch.
Prepare the master branch for the next development cycle:
git checkout master; git pull
VERSIONfile to contain
git addand create & merge a PR titled
Prepare for 1.3.0 development.
- Update the release branch on
Jenkins to be tested on every change and Nightly.
(Only 1.0 minor releases) Tag newest 1.0.x Docker image as
v1.0-stableand push it to Docker Hub. This will ensure that Kops uses latest 1.0 release by default.