mirrors/brew
1
0
Fork 0
mirror of https://github.com/Homebrew/brew.git synced 2025-07-14 16:09:03 +08:00
Code Issues Packages Projects Releases Wiki Activity
brew/docs/Releases.md
Mike McQuaid da0e0884df
docs/Releases: update process documentation. 
- Note that Homebrew/homebrew-core CI jobs should complete successfully
  before creating a release
- No code changes only required for 4 hours, 24 hours is a bit
  excessive/unrealistic
- Note that commented `odeprecated` code should be uncommented
- TinyLetter emails are no longer required (MailChimp does so
  automatically from the RSS feed)
- Note that `brew release` will output the major/minor blog post content
  (after #10499 is merged) instead of referencing the now-deprecated
  `brew release-notes`
- Note why you should not create a release on older `master` commits and
  provide an alternate process to handle this case
- Various style tweaks
2021-02-05 08:52:57 +00:00

3.0 KiB
Raw Blame History

Releases

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 get new versions of Homebrew. There are a few steps in making a new Homebrew release:

  1. Check the Homebrew/brew pull requests, issues, Homebrew/homebrew-core issues and Homebrew/discussions (forum) to see if there is anything pressing that needs to be fixed or merged before the next release. If so, fix and merge these changes.
  2. Ensure that no code changes have happened for at least a couple of hours (ideally 4 hours), at least one Homebrew/homebrew-core pull request CI job has completed successfully, checked the state of the Homebrew/brew master CI job (i.e. main jobs green or green after rerunning), and that you are confident there are no major regressions on the current master, branch.
  3. Run brew release to create a new draft release. For major or minor version bumps, pass --major or --minor, respectively.
  4. Publish the draft release on GitHub.

If this is a major or minor release (e.g. X.0.0 or X.Y.0) then there are a few more steps:

  1. Before creating the tag you should delete any odisabled code, make any odeprecated code odisabled, uncomment any # odeprecated code and add any new odeprecations that are desired.
  2. Write up a release notes blog post to 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.
  3. 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).
  4. Consider whether to submit it to other sources e.g. Hacker News, Reddit.
  • Pros: gets a wider reach and user feedback
  • Cons: negative comments are common and people take this as a chance to complain about Homebrew (regardless of their usage)

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.