可接受的公式
有些公式不應放在 homebrew/core 中。但還有其他 有趣的 Tap 和 Fork，而且任何人都可以 開始自己的 Tap！
homebrew/core 的需求
支援的平台
該公式需要在最新 3 個支援的 macOS 版本（x86_64 和 Apple Silicon/ARM）和 x86_64 Linux 上建置並通過測試。請查看 homebrew/core 中拉取請求上的持續整合工作，以查看作業系統的完整清單。如果上游不支援其中一個平台，則可以例外處理，並針對該平台停用該公式。
系統套件的重複項
我們現在接受隨 macOS 提供的項目，只要它使用 keg_only :provided_by_macos 預設為僅 keg。
版本化的公式
我們現在接受版本化的公式，只要它們 符合需求。
通常不是 Fork
除非符合下列其中一項，否則我們不會新增使用 Fork 的新公式
- Fork 已在原始原始碼儲存庫（例如在 README 中）或由原始作者以公開可驗證的方式（例如在問題或拉取請求評論中）指定為官方繼承者
- Fork 已被至少兩個其他主要發行版（例如 Debian、Fedora、Arch、Gentoo，而不是廣泛使用的較小 Linux 發行版）用作替代品
Fork 仍必須符合所有其他可接受的公式需求（包括例如普及性和自提交）。
替代 Fork 取代原始公式的方法是使用新公式。例如，如果 MikeMcQuaid 分叉 curl 且它非常受歡迎：curl-mikemcquaid 公式可能是有意義的。
我們不喜歡會自行升級的工具
可以自行升級的軟體與 Homebrew 配方本身的升級功能無法順利整合。應停用自行更新功能（同時將配方的複雜性降到最低）。Cask 允許（且支援良好）此功能。
我們不喜歡會下載未版本化項目的安裝腳本
我們不喜歡從 Git 儲存庫的主分支或未版本化、未校驗雜湊的 tarball 提取的安裝指令碼。理想情況下，這些指令碼應使用具有特定版本或校驗雜湊的 tarball 的 resource 區塊。請注意，我們現在允許 cargo、gem 和 pip 等工具在安裝過程中下載版本化程式庫。當我們可以呼叫語言套件管理員的功能時，無需使用 resource 區塊複製其功能。
我們不喜歡二進制公式
我們的政策是核心 tap (homebrew/core) 中的配方必須是開源的，並具有 Debian 自由軟體指南許可證，且從原始碼建置或產生跨平台二進位檔（例如 Java、Mono）。僅二進位檔的配方應放入 homebrew/cask。
此外，核心配方也不得依賴於 cask 或任何其他專有軟體。這包括在執行階段自動安裝 cask。
穩定版本
核心儲存庫中的配方必須具有上游專案標記的穩定版本。優先使用 tarball 而不是 Git 簽出，並且 tarball 應盡可能在檔名中包含版本。
我們不接受沒有標記版本的軟體，因為它們會因上游變更而定期中斷，而且我們無法為它們提供 瓶子。
利基（或自提交）項目
有問題的軟體必須
- 受到維護（即最後一次發布不是很久以前，它可以在所有 Homebrew 支援的作業系統版本上無需修補就能運作，並且沒有未修補的安全性漏洞）
- 穩定（例如，未由上游宣告為「不穩定」或「測試版」）
- 廣為人知（例如，GitHub 儲存庫應有 >=30 個分岔、>=30 個追蹤者或 >=75 個星號）
- 被使用
- 有首頁
我們會拒絕看似太過模糊的配方，部分原因是它們不會受到維護，部分原因是我們必須在某處劃清界線。
我們不贊成作者提交自己的作品，除非它非常流行。
別忘了 Homebrew 在底層都是 Git！如果您必須的話，維護您自己的 tap！
主要儲存庫中可能會有一些例外情況；我們可能會包含不符合這些準則或拒絕符合這些準則的事項。請相信我們需要根據我們經營套件管理員的經驗來運用我們的判斷力。
會建置 .app 的項目
不要讓您的配方建置 .app（原生 macOS 應用程式）；我們不希望在 Homebrew 中有這些東西。鼓勵上游專案建置並支援 .app，以便 homebrew/cask 可以發行（也可以不用它）。
預設會建置 GUI 的項目（但不是必須）
預設情況下，讓它建置命令列工具或程式庫，如果 GUI 有用且會被廣泛使用，也建置 GUI。不要建置 X11/XQuartz GUI，因為它們在 macOS 上的使用者體驗不佳。
無法使用最新穩定 Xcode Clang 建置的項目
Clang 是 macOS 上的預設 C/C++ 編譯器（而且已經很長一段時間了）。無法使用它來建置的軟體並未適當地移植到 macOS。
需要大量手動預/後安裝介入的項目
我們是一個套件管理員，因此我們想要執行一些動作，例如解析相依性並為我們的使用者設定應用程式。如果事情需要太多手動介入，那麼它們在套件管理員中就沒有用。
共用 vs. 靜態函式庫
一般來說，如果公式必須提供共用或靜態函式庫：它們應該提供共用函式庫。如果對靜態函式庫有興趣，它們可以同時提供。如果可能，應避免僅提供靜態函式庫，特別是在公式依賴於其他公式時，因為這些相依項無法在不重新建置的情況下更新。
需要 Homebrew 公式的供應商版本的項目
Homebrew 公式應避免將多個獨立的上游專案綑綁在單一套件中，以避免提供已成為公式的軟體的過時/不安全的版本。Veracode 的 軟體安全性報告 結論
事實上，79% 的時間，開發人員在將第三方函式庫包含在程式碼庫中後，從未更新它們。
有關更多資訊，請參閱 Debian 和 Fedora 對此的立場。
然而，這可能會變得（太）困難。Homebrew 的主要任務是實用，而不是意識形態上的純粹。如果我們無法在不使用供應的上游版本的情況下封裝某些東西：那就這樣吧；最好在 Homebrew 中封裝軟體，而不是不封裝。
有時會有例外
即使符合所有條件，我們也可能不接受公式。即使不符合某些條件，我們也可能接受公式。新公式的標準高於現有公式。文件將落後於目前的決策制定。儘管有些拒絕可能看似武斷或奇怪，但它們是基於多年來讓 Homebrew 能為我們的使用者可接受地運作的經驗。
