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
Update the contents of the
CODEOWNERSfile to reduce code reviews to essential approvals:
* @cilium/tophatfallback entry.
/.github/workflows/entry for CI/CD security.
@cilium/apiassignments for API stability on the release branch.
Remove everything else so that it is handled by the Top Hat.
git rm stable.txt
Create a new project named “X.Y.Z” to automatically track the backports for that particular release. Direct Link:
.github/maintainers-little-helper.yamlfrom 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:
Set the right version for the
pkg/k8s/...by following these instructions:
install/kubernetes/Makefile.valuesfor the new branch.
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/maintainers-little-helper.yamlto have all the necessary configurations for the backport of the new
vX.Ybranch. Specifically, ensure that:
The project at the top of the file points to the “next” release,
A new section is added for the upcoming release that is being prepared, and
The section for the oldest release is removed.
$ git checkout -b pr/master-cilium-actions-update origin/master $ # modify .github/maintainers-little-helper.yaml $ git add .github/maintainers-little-helper.yaml $ 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.
Update Grafana dashboards in Grafana. Install the dashboards available in
./examples/kubernetes/addons/prometheusand use them to upload them to Grafana.
For the final release
Follow the Generic Release Process to create the final replace and replace
Announce to Slack with a more thorough release text. Sample text:
@channel :cilium-new: **Announcement:** Cilium 1.7.0 is out! :tada: <Short summary of major features pulled from Blog, eg:> *Amazing Technology*: Just some of the great work the community has been working on over the past few months. For more information, see the blog post: https://cilium.io/blog/2020/02/18/cilium-17
SECURITY.mdto represent the security support for the most recent three release series.
Set the branch for the oldest release (now EOL) as “Active” and “Hidden” in the readthedocs Admin page. (Replace
v1.2with the right branch)