本文主要介绍我们是如何进行极狐GitLab 自助服务版（self-managed）的版本发布的，对于线上 SaaS 服务（jihulab.com）的版本发布，目前我们采用的是和 gitlab.com 类似的 auto-deploy 机制，详见此处。
极狐GitLab 自助服务版的版本发布节奏与 GitLab EE 的版本发布节奏保持一致（详见此处），也就是包括 major、minor 和 patch release 三种版本发布。GitLab EE 的所有版本发布都可以在此处查看，极狐GitLab 的版本发布可以在此处查看（目前仅包含月度版本发布）。
GitLab Inc. 会为 GitLab EE 的每个 major 和 minor release 提前从GitLab upstream repo的 master 分支创建出相应的 stable 分支，比如：14.0(major release) 的 stable 分支是 14-0-stable-ee，14.1(minor release) 的 stable 分支是 14-1-stable-ee。对于极狐GitLab 的 major 和 minor release，我们也是类似的做法，只不过 stable 分支创建在极狐GitLab repo，且分支名的后缀从 ee 变为了 jh，比如：14-0-stable-jh。最终的 release 是通过一个 release tag 来标识的，比如：对于 14.0，GitLab EE 的 release tag 是 v14.0.0-ee，极狐GitLab 的 release tag 是 v14.0.0-jh。
GitLab Inc. 会为每个 release 都创建一个 release issue 并在其中列出针对该 release 所需完成的任务（比如：创建 stable 分支和 release tag），比如：14.0的release issue，而我们也会为极狐GitLab 的每个 release 创建对应的 release issue，比如：极狐GitLab 14.0的release issue。
关于我们创建极狐GitLab stable 分支的方式，详见此 issue 中的讨论。
Patch release 和 major/minor release 的区别在于我们无需为其创建 stable 分支，它是通过在与之相对应的 major 或 minor release 的 stable 分支上创建 release tag 来完成的，比如：对于 14.0.1 这个 patch release，GitLab Inc. 会为其在 14-0-stable-ee 分支上创建 v14.0.1-ee 的 release tag，而我们则会在 14-0-stable-jh 分支上创建 v14.0.1-jh 的 release tag。极狐GitLab patch release 的 release issue 可参见这个issue。
针对 Patch release 我们建立了自动化发布流程，详见此处。
Security release 的流程和 Patch release 一样，但我们会在上游发布前收到相关通知，详见 JiHu Support Security Release Process。
有版本发布问题可以在 slack channel jh-release 中提问。
最直观有效的方法是在对应 release tag 的提交历史中查看，是否有相关 commit，例如 v15.9.0-jh 的提交历史。
如果是上游的 MR，通常情况在 15th 之前合入的可以进入，在 15-20th 之间的也有可能，具体说明参见这里。
如果是 JH 的 MR，我们会在上游的月度稳定分支建立后，找到该分支是具体在哪个 commit 从 master 切出来的，并根据这个上游的 commit 找到时间上最接近的 JH commit，这个 commit 之后的提交都不在该版本中，参见Release 15.8 的发布流程。
JH release 的节奏跟 upstream 保持一致，我们当前并没有单独发布 JH release 的机制。
上游对 Patch release 的政策是，Patch release 仅包括 bug fixes，所以新 feature 不应该进入 patch release。如果某个 bug fix 需要进入 patch release，可以给 MR 加上类似 Pick into 15.1 的标签，在下次发布 15.1.* 的 patch 时会自动 Cherry pick 这个 MR 进入 patch release，详见此处。
