从 -stable 分支发布新版本
除了默认的 master 分支会发布正式版本之外，Jekyll Core 有时也会为仍在维护的旧版本发布包含安全补丁和关键 Bug 修复的版本。
这些版本会从专门命名的分支发布，命名规则如下：
[x].[y]-stable
其中 [x] 表示 semver 主版本号（major version），[y] 表示 semver 次版本号（minor version）。
例如，3.9-stable 分支对应的是 jekyll-3.9.x 系列版本中的提交内容。
由于默认分支最终也必须同步这些发布内容，因此从 *-stable 分支协调发布流程会更加复杂。
Requirements
- 维护者必须同时拥有对应
*-stable分支和master分支的 写入权限。 - 维护者必须通过自己的 本地 CLI 程序 完成整个流程，而不是通过 GitHub Web UI 操作。
- 维护者需要熟悉 从
master分支发布版本 的工作流程。 下方文档中的流程，是针对master工作流的简化适配版本。 - 发布公告（release post）已经提前编写完成，并且 正等待通过已批准的 Pull Request 发布到
master。 - 稳定的网络连接。
Trigger release workflow
- 确保你已经 切换到对应的
*-stable分支，并且已经同步到 GitHub 上jekyll/jekyll仓库中的最新状态。 - 更新
lib/jekyll/version.rb中的VERSION字符串。 - 按照这里的说明更新 History 文档。
（重要：不要在 stable 分支上运行rake site:generate） - 将当前版本对应的整个 History 更新内容复制出来，粘贴到文本编辑器的新标签页或新窗口中。 后面的步骤还会用到这段临时内容。
- 提交版本文件和 History 文档修改，提交信息使用：
Release 💎 v[CURRENT_VERSION] - 将提交推送到 GitHub 上游仓库
jekyll/jekyll。
Publish release post
- 确认
Release Gem工作流已经成功执行完成。 - 将发布公告对应的 Pull Request 合并到
master分支。
Update default branch to reflect release off the stable branch
- 在本地切换到
master分支，并确保它已经同步到 GitHub 上jekyll/jekyll仓库中的最新状态。 - 使用之前临时保存的内容更新 History 文档。
History 文档中的各个版本记录，主要按照时间倒序排列，其次再按 semver 主版本号分类。
例如，
v3.9.2的发布记录会排在v3.9.1上方，但整体仍位于 v4.x 版本记录下方。 因此，之前保存的那段内容需要手动插入到正确位置。 - 可选：更新
lib/jekyll/version.rb中的VERSION字符串。 （仅当当前版本号低于最新版本时） -
现在执行
rake site:generate来更新多个元数据文件：- docs/_config.yml
- docs/_docs/history.md
- docs/latest_version.txt
- 提交这些元数据文件修改，提交信息使用：
Release 💎 v[CURRENT_VERSION] - 将提交推送到上游仓库。
Publish GitHub Release
与从 master 分支发布版本不同，JekyllBot 不会自动为从 非默认分支 创建的标签生成并发布 GitHub Release。
因此，维护者需要 手动创建并发布 对应的 GitHub Release。
- 选择刚刚推送的新标签。
- 标题与所选标签名称保持一致。
- 使用之前保存的发布内容作为正文。
- 删除正文中的标题部分（
## x.y.z / YYYY-MM-DD）。 - 点击发布。
注意：为了简化流程，可以选择先提前创建 草稿版 GitHub Release，等默认分支更新提交推送完成后，再立即正式发布。