Some formulae should not go in homebrew/core. But there are additional Interesting Taps and Forks and anyone can start their own!
We now accept stuff that comes with macOS as long as it uses keg_only :provided_by_macos
to be keg-only by default.
We now accept versioned formulae as long as they meet the requirements.
Software that can upgrade itself does not integrate well with Homebrew's own upgrade functionality. The self-update functionality should be disabled (if possible without complicating the formula).
We don't like install scripts that are pulling from the master
branch of Git repositories or unversioned, unchecksummed tarballs. These should use resource
blocks with specific revisions or checksummed tarballs instead. Note that we now allow tools like cargo
, gem
and pip
to download specifically versioned libraries during installation.
Our policy is that formulae in the core tap (homebrew/core) must be open-source with an OSI-approved license and either built from source or produce cross-platform binaries (e.g. Java, Mono). Binary-only formulae should go to homebrew/cask.
Formulae in the core repository must have a stable version tagged by the upstream project. Tarballs are preferred to Git checkouts, and tarballs should include the version in the filename whenever possible.
We don鈥檛 accept software without a tagged version because they regularly break due to upstream changes and we can鈥檛 provide bottles for them.
The software in question must:
- be maintained (i.e. the last release wasn't ages ago, it works without patching on all supported macOS releases and has no outstanding, unpatched security vulnerabilities)
- be known
- be stable (e.g. not declared "unstable" or "beta" by upstream)
- be used
- have a homepage
We will reject formulae that seem too obscure, partly because they won鈥檛 get maintained and partly because we have to draw the line somewhere.
We frown on authors submitting their own work unless it is very popular.
Don鈥檛 forget Homebrew is all Git underneath! Maintain your own tap if you have to!
There may be exceptions to these rules in the main repository; we may include things that don't meet these criteria or reject things that do. Please trust that we need to use our discretion based on our experience running a package manager.
Don鈥檛 make your formula build an .app
(native macOS Application); we
don鈥檛 want those things in Homebrew. Encourage upstream projects to build and support a .app
that can be distributed by homebrew/cask (and used without it, too).
Make it build a command-line tool or a library by default and, if the GUI is useful and would be widely used, add an option to build the GUI. Don't offer an option for multiple GUI backends, e.g. X11 is a bad user experience for GUIs on macOS.
Clang is the default C/C++ compiler on macOS (and has been for a long time). Software that doesn't build with it hasn't been adequately ported to macOS.
We're a package manager so we want to do things like resolve dependencies and set up applications for our users. If things require too much manual intervention then they aren't useful in a package manager.
Even if all criteria are met we may not accept the formula. Documentation tends to lag behind current decision-making. Although some rejections may seem arbitrary or strange they are based on years of experience making Homebrew work acceptably for our users.