TL;DR

• We're moving to conventional commits with release automation driven by Semantic Release
• Make sure to follow the conventional commit format as part of PR titles
• You can cut a release by clicking a button

Problem statement

Our release process today has a few pain points

• A lot of manual steps (that are error prone, lead to variation in how releases are done, and take a long time to complete
• High learning curve (and uncertainty) for developer that are cutting a release for the first time

Solution

Overview

• Introduce Semantic Release with conventional commits in order to further automate release creation.
• Give up on some less important processes (e.g, forward porting changelogs from release branches to master)
• PR titles will be enforced by a GitHub Action
• Prow will be modified to use the PR title as part of the commit title

What's the new process?

(depends on #2332)

Follow the conventional commit format as part of PR titles

PRs will get squashed into commits that follow the same conventional commit format

Over time you will have a bunch of unreleased commits on the master branch. If you want to cut a release, simply head over to GitHub Actions and create a release

This will automatically trigger a release pipeline that determines the new release version, creates a changelog based on these conventional commits, commits the changelog, creates a tag, creates a GitHub release, and pushes the created tag to master. In turn, that tag push will trigger the building and publishing of artifacts (wheels, charts, jars, etc).

Release branches work the same, with one difference. You need to backport (cherry-pick) the relevant fix: **** commits to the release branch (like v0.18-branch) and then trigger a release using the same release form on GitHub Actions.

Limitations

• You cant publish ONLY a patch (bug fix) on master. If you want to go from 0.18.0 to 0.18.1 then you should cut a release on v0.18-branch not master.
• You can't publish features or breaking changes from a release branch. That means you should not try to backport feature releases or breaking changes to release branches.

Process changes

• Minimize patch releases: Patch releases require us to commit fixes to master and backport patches to release branches. Only backport fixes to a release branch and release a patch if a patch is critical. Instead, focus on getting a new minor release out faster (0.18.0→0.19.0)
• Don’t forward port changelogs for patches: Today, if you release a patch (0.18.0→0.18.1) then you need to copy/cherry-pick the created changelog to the master branch. This adds relatively little value since all the fixes on that branch are also contained in the minor release (0.18.0→0.19.0), and the release log will always be visible on GitHub itself.
• Pre-releases (not implemented yet): If users really need access to small fixes on master, then we can automate the publishing of pre-releases from master.