Release Process

Change milestone

  • 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 to change this line
      • Example PR:

Create a tag

  • Identify a known good commit on the main branch
  • Fast-forward the release branch to the selected commit. :warning: Always release from the release branch and not from main!
    • git checkout release-0.x
    • git fetch upstream
    • git merge --ff-only upstream/main
    • git push
  • Create tag with git
    • export RELEASE_TAG=v0.4.6 (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 account
    • git 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
  • Create a PR in to add the image and tag
    • Example PR:
  • Location of image:

Release in GitHub

  • Manually format and categorize the release notes
  • Publish release
  • Announce the release


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

  1. A release yaml file infrastructure-components.yaml containing the resources needed to deploy to Kubernetes
  2. A cluster-templates.yaml for each supported flavor
  3. A metadata.yaml which maps release series to cluster-api contract version
  4. Release notes


Patch Releases

  1. Announce the release in Kubernetes Slack on the #cluster-api-azure channel.

Minor/Major Releases

  1. Follow the communications process for pre-releases
  2. An announcement email is sent to and with the subject [ANNOUNCE] cluster-api-provider-azure <version> has been released