Since Homebrew 1.0.0 most Homebrew users (those who havenโt run a dev-cmd
or set HOMEBREW_DEVELOPER=1
which is ~99.9% based on analytics data) require tags on the Homebrew/brew repository in order to receive new versions of Homebrew. There are a few steps in making a new Homebrew release:
Homebrew/brew
pull requestsHomebrew/brew
issuesHomebrew/homebrew-core
issuesIf so, fix and merge these changes.
master
CI job is clear (i.e. main jobs green or green after rerunning)master
branch.Run brew release
to create a new draft release. For major or minor version bumps, pass --major
or --minor
, respectively.
If this is a major or minor release (e.g. X.0.0 or X.Y.0) then there are a few more steps:
odisabled
code,odeprecated
code odisabled
,# odeprecated
codeodeprecations
that are desired.Also delete any command argument definitions that pass replacement: ...
.
Write up a release notes blog post for https://brew.sh (e.g. brew.sh#319). This should use the output from brew release [--major|--minor]
as input but have the wording adjusted to be more human readable and explain not just what has changed but why.
When the release has shipped and the blog post has been merged, tweet the blog post as the @MacHomebrew Twitter account or tweet it yourself and retweet it with the @MacHomebrew Twitter account (credentials are in 1Password).
Please do not manually create a release based on older commits on the master
branch. Itโs very hard to judge whether these have been sufficiently tested by users or if they will cause negative side effects with the current state of Homebrew/homebrew-core. If a new branch is needed ASAP but there are things on master
that cannot be released yet (e.g. new deprecations and you want to make a patch release) then revert the relevant PRs, follow the process above and then revert the reverted PRs to reapply them on master
.