公式版本
homebrew/core 使用特殊命名格式來支援多個版本的公式。例如，GCC 6 的公式命名為 gcc@6.rb，並以 class GccAT6 < Formula 開頭。
可接受的版本化公式
我們包含在 homebrew/core 中的版本化公式必須符合以下標準
- 版本化軟體應建立在 Homebrew 所有支援的 macOS 版本上。
- 版本化公式應與目前穩定版本在主要/次要版本（而非修補程式版本）上有所不同。這是因為修補程式版本表示錯誤或安全性更新，而我們希望確保您套用安全性更新。
- 不穩定的版本（alpha、beta、開發版本）不適用於版本化（或未版本化）公式。
- 上游應為每個公式版本提供一個發行分支，並在必要時為每個版本制定明確的安全性更新發行政策。例如，PHP 7.0 不是受支援版本，但 PHP 7.2 是（2020 年 1 月）。相比之下，大多數軟體專案的架構僅針對最新版本發行安全性更新，因此其較早版本不符合版本化的資格。
- 版本化公式應與主要公式共用一個程式碼庫。如果專案分割成不同的儲存庫，我們建議建立一個新公式（
formula2，而非formula@2或formula@1）。 - 依賴於版本化公式的公式不得在遞迴依賴關係中兩次依賴於同一個公式的不同版本。例如，如果您依賴於
openssl@1.0和foo，而foo依賴於openssl，則您必須改用openssl。 - 版本化公式僅在上游專案提供支援時，才能與其非版本化對應項同時連結，例如使用後綴二進位檔。如果無法做到這一點，請使用
keg_only :versioned_formula，以允許使用者一次安裝多個版本。 keg_only :versioned_formula不應在HOMEBREW_PREFIX中post_install任何與主要對應項（或其他版本化公式）衝突或重複的內容。例如，node@6公式不應將其npm安裝到HOMEBREW_PREFIX，就像node公式所做的那樣。- 提交的版本化公式應預期會被大量使用者使用。如果不再如此，它們將會被移除。我們的目標是不移除 前 3,000 個
install_on_request公式 中的那些公式。 - 版本化公式不應具有需要安全性更新的
resource。例如，node@6公式不應具有npm資源，而應依賴上游 tarball 所提供的npm。 - 與主要公式相比，版本化公式應盡可能相似且合理。建立或更新版本化公式應是一個機會，可以向主要公式提出問題，反之亦然，例如可以移除或設定某些未使用的或無用的選項為預設值嗎？
- 在任何特定時間，最多只會支援五個公式版本（包括主要版本），除非它們很受歡迎（例如在 分析 90 天安裝 中有超過 1000 個使用次數）。在移除違反此項規定時，我們的目標是根據使用情況和支援狀態，而不是根據年齡來執行此動作。
- 版本化公式在版本分支的存續期間內，其 ABI 必須保持穩定。對版本化公式的更新不得引入 ABI 不相容性，或要求依賴項進行版本升級。實際上，這表示其依賴項不應需要
revision升級，才能針對較新的版本進行重新建置。違反此規定的版本更新應予拒絕，並從該時點起將公式標示為已棄用。
不應使用 Homebrew 的版本來將公式「固定」到您的個人需求。您應為您或您的組織希望控制其版本的公式，或不符合上述標準的公式，建立您自己的 tap。定期發布 API 或 ABI 中斷版本的軟體仍須符合上述所有需求；brew upgrade 對您造成某些中斷並非我們為您新增和維護公式的理由。
如果目前在 Homebrew/homebrew-core 儲存庫中存在公式，或過去曾存在（即已移轉或刪除），您可以使用 brew extract 指令將其復原供您自己使用。這會將公式的所需版本複製到自訂 tap。例如，如果您的專案依賴 automake 1.12，而非最新版本，您可以透過執行下列指令取得版本 1.12 的 automake 公式：
brew extract automake --version=1.12 <YOUR_GITHUB_USER>/<YOUR_TAP_REPOSITORY_NAME>
透過此方式取得的公式可能包含已棄用、已停用或已移除的 Homebrew 語法（例如，檢查碼可能是 sha1，而非 sha256）；brew extract 指令不會編輯或更新公式，以符合目前的標準和樣式需求。
我們可能會暫時在 homebrew/core 中新增不符合這些標準的版本化公式，以滿足我們自己的需求。在其中存在版本化公式並不表示它會被無限期地維護，或表示我們願意接受任何不符合上述需求的版本。
