Release Process
Update metadata.yaml (skip for patch releases)
- Make sure the metadata.yaml file is up to date and contains the new release with the correct cluster-api contract version.
- If not, open a PR to add it.
Change milestone (skip for patch releases)
- Create a new GitHub milestone for the next release
- Change milestone applier so new changes can be applied to the appropriate release
- Open a PR in https://github.com/kubernetes/test-infra to change this line
- Example PR: https://github.com/kubernetes/test-infra/pull/16827
- Open a PR in https://github.com/kubernetes/test-infra to change this line
Create a tag
- Prepare the release branch. :warning: Always release from the release branch and not from main!
- If releasing a patch release, check out the existing release branch and make sure you have the latest changes:
git checkout release-1.x
git fetch upstream
git rebase upstream/release-1.x
- If releasing a minor release, create a new release branch from the main branch:
git fetch upstream
git rebase upstream/main
git checkout -b release-1.x
git push upstream release-1.x
- If releasing a patch release, check out the existing release branch and make sure you have the latest changes:
- Create tag with git
export RELEASE_TAG=v1.2.3
(the tag of the release to be cut)git tag -s ${RELEASE_TAG} -m "${RELEASE_TAG}"
-s
creates a signed tag, you must have a GPG key added to your GitHub accountgit push upstream ${RELEASE_TAG}
This will automatically trigger a Github Action to create a draft release.
Promote image to prod repo
- Images are built by the post push images job. This will push the image to a staging repository.
- If you don’t have a GitHub token, create one by going to your GitHub settings, in Personal access tokens. Make sure you give the token the
repo
scope. - Wait for the above job to complete for the tag commit and for the image to exist in the staging directory, then create a PR to promote the image and tag:
export GITHUB_TOKEN=<your GH token>
make promote-images
This will automatically create a PR in k8s.io and assign the CAPZ maintainers. Example PR: https://github.com/kubernetes/k8s.io/pull/3007.
Release in GitHub
- Manually format and categorize the release notes
- Publish release
- Announce the release
Versioning
cluster-api-provider-azure follows the semantic versionining specification.
Example versions:
- Pre-release:
v0.1.1-alpha.1
- Minor release:
v0.1.0
- Patch release:
v0.1.1
- Major release:
v1.0.0
Expected artifacts
- A release yaml file
infrastructure-components.yaml
containing the resources needed to deploy to Kubernetes - A
cluster-templates.yaml
for each supported flavor - A
metadata.yaml
which maps release series to cluster-api contract version - Release notes
Update Upstream Tests
For major and minor releases we will need to update the set of capz-dependent test-infra
jobs so that they use our latest release branch. For example, if we cut a new 1.3.0
minor release, from a newly created release-1.3
git branch, then we need to update all test jobs to use capz at release-1.3
instead of release-1.2
.
Here is a reference PR that applied the required test job changes following the 1.3.0
minor release described above:
- https://github.com/kubernetes/test-infra/pull/26200
Communication
Patch Releases
- Announce the release in Kubernetes Slack on the #cluster-api-azure channel.
Minor/Major Releases
- Follow the communications process for pre-releases
- An announcement email is sent to
kubernetes-sig-azure@googlegroups.com
andkubernetes-sig-cluster-lifecycle@googlegroups.com
with the subject[ANNOUNCE] cluster-api-provider-azure <version> has been released