All About Releases
This document describes how we organize new features, bugfixes, and other additions to our codebase into releases.
A release is a GitHub Release, its associated Git tag, and a set of Docker images on quay.io that are all tagged with the Git tag. The images never change, and are intended to be an immutable artifact. Anyone should be able to reference them with confidence that they will never change.
Release pipeline is very similar to the pipeline that is triggered for every commit on the master branch, but it sets different versions and creates a Helm chart:
We support two major versions of Service Catalog:
- v0.2 - deprecated, API-server-based
- v0.3 - the current master branch, CRDs-based
During the release process three types of artifacts are created:
- docker images
- svcat binaries
- Helm charts
They are created for the following platforms: amd64, arm, arm64, ppc64le, s390x
All artifacts from the v0.2 branch that are created after the v0.3 version, are followed with the -v0.2 suffix. It means that we can easily create bug-fix releases for the deprecated version without interfering with the current releases.
At the time of this writing, we are in the 0.3.x release family. If you are a core maintainer and need to run a release, please see the document about the release process for instructions. We do not currently create a branch, and thus do not update a release after it is created.
Pull requests and issues are scheduled for a release by being tagged with a milestone that corresponds to that release. These milestones correspond to the entries on our roadmap. Core maintainers are responsible for updating the roadmap and organizing pull requests and issues into the appropriate milestones.
@MHBauer will run the release each week, or delegate if unavailable.
The person running the release is the release organizer. They should try to ensure that there are no pending pull requests that could or ought to get merged before the release is cut. If there is a merge between creating the release PR and the release PR build finishing, it should be re-run to ensure a green build at the end.
The helm chart will be automatically updated by a process under control of the chart repo.