RubyGems 发布的运行手册。

RubyGems 的发布流程比大多数 gem 复杂。RubyGems 更新打包在一个 包装 gem 中，该 gem 由 gem update --system 命令下载，然后运行 setup.rb.

RubyGems 在其版本编号中遵循 语义版本控制。

注意：在下面列出的文档中，*当前* 次要版本号为 2.7，*下一个* 次要版本号为 2.8

无论版本如何，所有发布 都必须更新 History.txt 和 lib/rubygems.rb 文件。第一个稳定次要版本 (2.7.0) 的变更日志是该次要版本所有先前预发布版本 (2.7.pre.1, 1.12.pre.2 等) 的总和。第一个稳定次要版本的变更日志为空，除非自上次预发布/候选发布以来包含修复。

工作流程

通常，master 将接受针对以下内容的 PR

• 下一个次要版本 (2.8) 的功能合并
• 当前次要版本 (2.7) 的补丁版本的回归修复合并

重大版本

RubyGems 非常重视保持兼容性。因此，破坏向后兼容性的更改应该（只要有可能）包含一个向后兼容的功能版本，并针对所有将要更改的选项和行为发出警告。

我们尽力只在增加 RubyGems 的 *主要* 版本时发布重大更改。

樱桃采摘

补丁版本是通过从 master 中挑选错误修复来完成的。

当我们进行樱桃采摘时，我们使用以下命令挑选合并提交

$ git cherry-pick -m 1 MERGE_COMMIT_SHAS

./util/patch_with_prs.rb 实用程序将自动处理樱桃采摘，并在下面详细介绍。

历史

RubyGems 在 History.txt 文件中维护着每个版本中存在的更改列表。在使用 ./util/update_changelog.rb 实用程序进行发布之前，会立即添加条目。通常，每个包含在发布中的 PR 都会获得一个条目。

发布

次要版本

虽然将 gem 版本推送到 RubyGems.org 就像 rake release 一样简单，但发布新版本的 RubyGems 包含很多沟通：团队共识、git 分支、更改日志编写、文档站点更新和博客文章。

头晕了吗？我们也是。

以下是发布新次要版本的清单

• 与核心团队核实，确保对发布功能版本达成共识。一般来说，这应该总是可以的，因为功能 *绝不破坏向后兼容性*
• 从 master 创建一个新的稳定分支（参见下面的 **分支**）
• 将 lib/rubygems.rb 中的 VERSION 常量更新为新的版本号
• 更新 History.txt 以包含发布中的所有更改
• 运行 rake release，发推文，写博客，让人们知道预发布！

此时，您就是发布经理！给自己倒几杯美味的饮料，想想去热带地区度假吧。

注意，在次要版本系列中的第一个版本发布后的头几天，通常会产生很多错误报告。这是正常的，并不意味着您作为发布经理做错了 *任何* 事情。

分支

下一个版本的次要版本从当前 master 状态开始，使用新的发布分支：2.7。

一旦从 master 中切出了该稳定分支，该次要版本系列 (2.7) 的更改将 *有意* 进行，通过补丁版本进行。也就是说，默认情况下，对 master 的更改 *不会* 进入任何 2.7 版本，并且对 master 的开发将针对下一个次要版本或主要版本。

补丁版本（错误修复！）

发布新的 bug 修复版本非常简单。在 lib/rubygems.rb 中递增微版本号，并在 History.txt 中为每个修复的 bug 添加一个项目符号。然后从 2.7（稳定）分支运行 rake release，给自己倒一杯美味的饮料！

包含当前次要版本补丁发布的回归修复的 PR 会合并到 master 分支。然后，这些提交将从 master 分支 cherry-pick 到次要分支 (2.7)。

有一个 ./util/patch_with_prs.rb 工具可以自动创建补丁发布。它接受一个选项，即要进行的补丁发布的确切版本（例如 --version=2.7.8），所有其他参数都是要包含在补丁发布中的 PR 号码。该工具会检出相应的稳定分支 (2.7)，然后将这些更改（仅这些更改）cherry-pick 到稳定分支。然后，该任务会将版本文件中的版本号递增，提示您更新 History.txt，然后会提交这些更改并运行 rake release！