Skip to content
This repository has been archived by the owner on May 6, 2022. It is now read-only.

Release Process

Mateusz Szostok edited this page Aug 26, 2019 · 33 revisions

This document describes how we organize new features, bugfixes, and other additions to our codebase into releases.

What a Release Is

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.

Details

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:

Service Catalog Release Process

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.

Schedule

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.

Organizing Each Release

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.

Release Organizer

@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.

Clone this wiki locally