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 https://github.com/kubernetes/test-infra to change this line
  - Example PR: https://github.com/kubernetes/test-infra/pull/16827

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.

Images are built by the post push images job
Create a PR in https://github.com/kubernetes/k8s.io to add the image and tag
- Example PR: https://github.com/kubernetes/k8s.io/pull/1030/files
Location of image: https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api-azure/GLOBAL/cluster-api-azure-controller?rImageListsize=30

cluster-api-provider-azure follows the semantic versionining specification.

Example versions:

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

Follow the communications process for pre-releases
An announcement email is sent to kubernetes-sig-azure@googlegroups.com and kubernetes-sig-cluster-lifecycle@googlegroups.com with the subject [ANNOUNCE] cluster-api-provider-azure <version> has been released