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. 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
    
  7. Create the following GitHub labels:

    1. backport-pending/1.2
    2. backport-done/1.2
    3. backport/1.2
    4. needs-backport/1.2
  8. 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.

    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
    
  9. Continue with the next step only after the previous steps are merged into master.

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

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

  12. 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/

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

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

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

    git checkout master; git pull
    
  16. Update the VERSION file to contain v1.2.90

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

  18. Update the release branch on

    Jenkins to be tested on every change and Nightly.

  19. (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.