Generic Release Process¶
This process applies to all releases other than feature releases, this includes:
- Stable releases
If you intent to release a new feature release, see the Feature Release Process section instead.
Note
The following commands have been validated when ran in the VM used in the Cilium development process. See Development Setup for detailed instructions about setting up said VM.
Ensure that the necessary backports have been completed and merged. See Backporting process.
- Update GitHub project and create
vX.Y.Z+1
project if applicable. - Update PRs / issues that were added to the
vX.Y.Z
project, but didn’t make it into this release into thevX.Y.Z+1
project.
- Update GitHub project and create
Checkout the desired stable branch and pull it:
git checkout v1.0; git pull
Create a branch for the release pull request:
git checkout -b pr/prepare-v1.0.3
Update the
VERSION
file to representX.Y.Z+1
If this is the first release after creating a new release branch. Adjust the image pull policy for all
.sed
files ininstall/kubernetes/cilium/values.yaml
fromAlways
toIfNotPresent
.Update Helm chart documentation
- Update
version
andappVersion
ininstall/kubernetes/cilium/Chart.yaml
- Update version tag in
install/kubernetes/cilium/values.yaml
- Update
Update the image tag versions in the examples:
make -C install/kubernetes clean all
Update the
cilium_version
andcilium_tag
variables inexamples/getting-started/Vagrantfile
Update the
AUTHORS file
make update-authors
Note
Check to see if the
AUTHORS
file has any formatting errors (for instance, indentation mismatches) as well as duplicate contributor names, and correct them accordingly.Generate the release notes by running the instructions provided in github.com/cilium/release
Set the right version for the
CustomResourceDefinitionSchemaVersion
in thepkg/k8s/client
by following these instructions:Run
./Documentation/check-crd-compat-table.sh vX.Y
Add all modified files using
git add
and create a commit with the titlePrepare for release v1.0.3
.Add the generated release notes in the
CHANGELOG.md
fileAdd all modified files using
git add
and create a pull request with the titlePrepare for release v1.0.3
. Add the backport label to the PR which corresponds to the branch for which the release is being performed, e.g.backport/1.0
.Note
Make sure to create the PR against the desired stable branch. In this case
v1.0
Follow standard procedures to get the aforementioned PR merged into the desired stable branch. See Submitting a pull request for more information about this process.
Checkout out the stable branch and pull your merged changes:
git checkout v1.0; git pull
Build the container images and push them
DOCKER_IMAGE_TAG=v1.0.3 make docker-image docker push cilium/cilium:v1.0.3
Create release tags:
git tag -a v1.0.3 -m 'Release v1.0.3' git tag -a 1.0.3 -m 'Release 1.0.3'
Note
There are two tags that correspond to the same release because GitHub recommends using
vx.y.z
for release version formatting, and ReadTheDocs, which hosts the Cilium documentation, requires the version to be in formatx.y.z
For more information about how ReadTheDocs does versioning, you can read their Versions Documentation.Push the git release tag
git push --tags
Build the binaries and push it to the release bucket:
DOMAIN=releases.cilium.io ./contrib/release/uploadrev v1.0.3
This step will print a markdown snippet which you will need when crafting the GitHub release so make sure to keep it handy.
-
- Choose the correct target branch, e.g.
v1.0
- Choose the correct target tag, e.g.
v1.0.3
- Title:
1.0.3
- Check the
This is a pre-release
box if you are releasing a release candidate. - Fill in the release description with the output generated by github.com/cilium/release
- Use
contrib/release/pull-docker-manifests.sh
to fetch the official docker manifests for the release and add these into the Github release announcement. - Preview the description and then publish the release
- Choose the correct target branch, e.g.
Prepare Helm changes using the Cilium Helm Charts Repository and push the changes into that repository (not the main cilium repository):
./prepare_artifacts.sh /path/to/cilium/repository/checked/out/to/release/commit git push
Prepare Helm changes using the Cilium Helm Charts Repository for the vX.Y helm charts, and push the changes into that repository (not the main cilium repository):
In the
cilium/cilium
repository:git checkout vx.y -b vx.z-dev
- Change the
VERSION
file tox.y-dev
- Run
make -C install/kubernetes
In the
cilium/charts
repository:./prepare_artifacts.sh /path/to/cilium/repository/checked/out/to/release/commit git push
After pushing you can revert all the changes made in the local branch
x.y-dev
fromcilium/cilium
.Announce the release in the
#general
channel on Slack. Sample text::cilium-new: **Announcement:** Cilium vX.Y.Z has been released :tada: <If security release or major bugfix, short summary of fix here> For more details, see the release notes: https://github.com/cilium/cilium/releases/tag/vX.Y.Z
Update the
README.rst#stable-releases
section from the Cilium master branchBump the version of Cilium used in the Cilium upgrade tests to use the new release
Please reach out on the
#development
channel on Slack for assistance with this task.Update the
stable
tags forcilium
,cilium-operator
, andcilium-docker-plugin
on DockerHub.Check if all docker images are available before announcing the release:
make -C install/kubernetes/ check-docker-images
Update the following external tools and guides to point to the released Cilium version. This step is only required on a new minor release like going from
1.8
to1.9
.