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

Prepare branch, tag and release notes

  • Update the file metadata.yaml if is a major or minor release
  • Submit a PR for the metadata.yaml update if needed, wait for it to be merged before continuing, and pull any changes prior to continuing.
  • 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}"
    • git push upstream ${RELEASE_TAG}
  • make release from repo, this will create the release artifacts in the out/ folder
  • Install the release-notes tool according to instructions
  • Export GITHUB_TOKEN
  • Run the release-notes tool with the appropriate commits. Commits range from the first commit after the previous release to the new release commit.
release-notes --org kubernetes-sigs --repo cluster-api-provider-gcp \
--start-sha 1cf1ec4a1effd9340fe7370ab45b173a4979dc8f  \
--end-sha e843409f896981185ca31d6b4a4c939f27d975de
--branch <RELEASE_BRANCH_OR_MAIN_BRANCH>
  • Manually format and categorize the release notes

Promote image to prod repo

Promote image

  • 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/1462
  • Location of image: https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api-gcp/GLOBAL/cluster-api-gcp-controller?rImageListsize=30

To promote the image you should use a tool called cip-mm, please refer: https://github.com/kubernetes-sigs/promo-tools/tree/main/cmd/cip-mm

For example, we want to promote v0.3.1 release, we can run the following command:

$ cip-mm --base_dir=$GOPATH/src/k8s.io/k8s.io/k8s.gcr.io --staging_repo=gcr.io/k8s-staging-cluster-api-gcp  --filter_tag=v0.3.1

Release in GitHub

Create the GitHub release in the UI

  • Create a draft release in GitHub and associate it with the tag that was created
  • Copy paste the release notes
  • Upload artifacts from the out/ folder
  • Publish release
  • Announce the release

Versioning

cluster-api-provider-gcp follows the semantic versioning 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

The major and minor versions mirror the version of Cluster-API. Thus CAPG 1.11.x releases will use CAPI versions 1.11

The patch version is incremented for each release. Thus the first release of CAPG using CAPI 1.11 will 1.11.0, the second will be 1.11.1, etc

Branches

We maintain release branches to facilitate backporting fixes. These branches are named release-<major>.<minor>. Patch releases are tagged from the corresponding release branch.

Feature development happens on the main branch, and nightlies are released from the main branch also. While we aim to keep the main branch healthy, it is intended for development and testing, and should not be used in production.

As such, we will aim to keep the main branch up to date with the latest versions of all dependencies (go toolchain, CAPI, other go module dependencies).

Release branches lock to a particular minor version of CAPI, but will update other dependencies on these branches while they are supported. Currently we maintain only one release branch (and the main branch). Once a branch is no longer supported there will be no new releases of the corresponding minor, including no further security fixes.

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

Communication

Patch Releases

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

Minor/Major Releases

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