公式版本
homebrew/core 使用特殊命名格式支持公式的多版本。例如，GCC 6 的公式命名为 [email protected]，并以 class GccAT6 < Formula 开头。
可接受的版本化公式
我们在 homebrew/core 中包含的版本化公式必须符合以下标准
- 版本化软件应在 Homebrew 支持的所有 macOS 版本上构建。
- 版本化公式在主次版本（而非补丁版本）上应与当前稳定版本不同。这是因为补丁版本表示错误或安全更新，我们希望确保你应用安全更新。
- 不稳定版本（alpha、beta、开发版本）对于版本化（或非版本化）公式不可接受。
- 上游应为每个公式版本提供一个发布分支，并明确规定在必要时为每个版本发布安全更新。例如，PHP 7.0 不是受支持版本，但 PHP 7.2 是（截至 2020 年 1 月）。相比之下，大多数软件项目都只为其最新版本发布安全更新，因此其早期版本没有资格进行版本化。
- 版本化公式应与主公式共享代码库。如果项目被拆分为不同的存储库，我们建议创建一个新公式（
formula2，而不是formula@2或formula@1）。 - 依赖于版本化公式的公式不得在其递归依赖项中两次依赖于两个不同版本的相同公式。例如，如果你依赖于
[email protected]和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 中添加不满足这些标准的版本化公式以满足我们自己的需求。那里存在版本化公式并不意味着它会无限期地得到维护，或者我们愿意接受任何不满足上述要求的其他版本。
