Releasing

To read about what happens during a production deployment, see the release process deep dive doc.

To initiate a new production deployment:

script/release vX.Y.Z

See script/release --help for more information.

[!NOTE] Deployment workflow requires maintainer approval to run.

What this does is:

Builds Linux binaries on Ubuntu;
Builds and signs Windows binaries on Windows;
Builds, signs, and notarizes macOS binaries on macOS;
Uploads all release artifacts to a new GitHub Release;
A new git tag vX.Y.Z is created in the remote repository;
The changelog is generated from the list of merged pull requests;
Updates GitHub CLI marketing site with the contents of the new release;
Updates the gh Homebrew formula in the homebrew/homebrew-core repo.

[!NOTE] Homebrew/formulae.brew.sh makes new formula versions available every 15 minutes through scheduled CI workflow.

For more information, see https://docs.brew.sh/Formula-Cookbook#an-introduction

To test out the build system while avoiding creating an actual release:

script/release --staging vX.Y.Z --branch patch-1 -p macos

The build artifacts will be available via gh run download <RUN> -n macos.

General guidelines

Features to be released should be reviewed and approved at least one day prior to the release.
Feature releases should bump up the minor version number.
Breaking releases should bump up the major version number. These should generally be rare.

Test the build system locally

A local release can be created for testing without creating anything official on the release page.

Make sure GoReleaser is installed: brew install goreleaser
script/release --local
Find the built products under dist/.

Cleaning up a bad release

Occasionally, it might be necessary to clean up a bad release and re-release.

Delete the release and associated tag
Re-release and monitor the workflow run logs
Open pull request updating gh Homebrew formula with new SHA versions, linking the previous PR
Verify resulting Debian and RPM packages, Homebrew formula