Feature Release Process

This document describes the process for creating a major or minor feature release of Cilium.

On Freeze date

1. Fork a new release branch from master:

   git checkout master; git pull origin master
   git checkout -b v1.2
   git push

2. Protect the branch using the GitHub UI to disallow direct push and require merging via PRs with proper reviews. Direct link

3. Replace the contents of the CODEOWNERS file 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

4. Create a new project named “X.Y.Z” to automatically track the backports for that particular release. Direct Link:

5. Copy the .github/cilium-actions.yml from the previous release vX.Y-1 change the contents to be relevant for the release vX.Y and set the project: to be the generated link created by the previous step. The link should be something like: https://github.com/cilium/cilium/projects/NNN

6. Set the right version for the CustomResourceDefinitionSchemaVersion in the pkg/k8s/... by following these instructions:

   Run ./Documentation/check-crd-compat-table.sh vX.Y

7. Commit changes, open a pull request against the new v1.2 branch, and get the pull request merged

   git checkout -b pr/prepare-v1.2
   git add [...]
   git commit
   git push

8. Create the following GitHub labels:

   1. backport-pending/1.2
   2. backport-done/1.2
   3. backport/1.2
   4. needs-backport/1.2

9. Checkout to master and update the .github/cilium-actions.yml to have all the necessary configurations for the backport of the new vX.Y branch. 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/cilium-actions.yml
   git add .github/cilium-actions.yml
   git commit
   git push

10. Continue with the next step only after the previous steps are merged into master.

11. Mark all open PRs with needs-backport/x.y that have the milestone x.y

12. Change the VERSION file to contain the next rc version. For example, if we are branching v1.2 and still in the RC phase we need to change the VERSION file to contain the v1.2.0-rcX

13. Set the branch as “Active” and the “Privacy Level” to “Private” in the readthedocs Admin page. (Replace v1.2 with the right branch) https://readthedocs.org/dashboard/cilium/version/v1.2/

14. Since this is the first release being made from a new branch, please follow the Generic Release Process to release v1.2.0-rc1.

15. Alert in the testing channel that a new jenkins job needs to be created for this new branch.

16. Prepare the master branch for the next development cycle:

    git checkout master; git pull

17. Update the VERSION file to contain v1.2.90

18. Add the VERSION file using git add and create & merge a PR titled Prepare for 1.3.0 development.

19. Update the release branch on

    Jenkins to be tested on every change and Nightly.

20. (Only 1.0 minor releases) Tag newest 1.0.x Docker image as v1.0-stable and push it to Docker Hub. This will ensure that Kops uses latest 1.0 release by default.

For the final release

1. Follow the Generic Release Process to create the final replace and replace X.Y.0-rcX with X.Y.0.

2. 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

3. Update SECURITY.md to represent the security support for the most recent three release series.