Help us learn about your current experience with the documentation. Take the survey.

GitLab 发布和维护策略

Delivery Group 是维护策略的所有者，必须批准任何请求的更新。这遵循我们的 DRI 模式，旨在确保客户的可预测性。

GitLab 有严格的版本命名政策，以及主版本、次版本和补丁版本的发布节奏。新版本会在 GitLab 博客上宣布。

我们目前的政策是：

  • 仅对当前稳定版本进行错误修复回溯 - 请参阅下面的 补丁版本。
  • 将安全修复回溯到前两个月度版本以及当前稳定版本。在某些情况下（详见下面的 补丁版本），我们可能仅针对当前稳定版本解决安全漏洞，或在常规月度发布流程中解决，而不进行回溯。

在极少数情况下，发布经理可能会例外，回溯到超过前两个月度版本。有关更多信息，请参阅 回溯到旧版本。

版本控制

GitLab 使用 语义化版本控制 进行版本发布： (主版本).(次版本).(补丁版本)。

例如，对于 GitLab 版本 13.10.6：

  • 13 代表主版本。主版本发布是 13.0.0，但通常称为 13.0。
  • 10 代表次版本。次版本发布是 13.10.0，但通常称为 13.10。
  • 6 代表补丁号。

版本号的任何部分都可以递增到多位数字，例如 13.10.11。

下表描述了版本类型及其发布节奏：

版本类型 描述 节奏
Major 用于重大变更，或当对公共 API 引入任何向后不兼容的变更时。 每年一次。下一个主版本是 GitLab 18.0，计划于 2025 年 5 月 15 日发布。GitLab 默认每年 5 月安排主版本发布。
Minor 当向公共 API 引入新的向后兼容功能，引入次要功能，或推出一组较小功能时使用。 每月一次，安排在每月的第三个星期四。
Patch 用于修复不正确行为的向后兼容错误修复。请参阅 补丁版本。 每月两次，安排在月度次版本发布前一周的星期三和后一周的星期三。

维护的版本

以下 GitLab 发布版本目前处于维护状态：

  • 18.3 (bug and security fixes)
  • 18.2 (security fixes)
  • 18.1 (security fixes)

对于正在寻找即将发布的补丁版本的维护版本的 GitLab 团队成员，请参考内部 Grafana 仪表板 “delivery: Release Information” 中 “Patch Release Information” 部分下的 “Release Versions”。 当活动月度发布日期早于活动补丁发布日期时，它们将与上述维护版本列表不同。

错误修复回溯仅维护当前（第一个）版本，安全修复回溯维护所有版本。

升级建议

我们鼓励每个人都运行 最新的稳定版本， 以确保您可以升级到最安全和功能最丰富的 GitLab 体验。 为了确保您可以运行最新的稳定版本，我们正在努力保持更新过程的可靠性。

如果您无法遵循我们的月度发布周期，有几个情况您必须考虑。请遵循 升级路径指南 来安全地在版本之间升级。

Linux 包的特定版本变更文档适用于：

提供了下载 Linux 包到本地并手动安装的说明。

升级 Linux 包捆绑的 PostgreSQL 的分步指南有单独文档。

升级主版本

向后不兼容的变更和迁移保留给主版本。有关更多信息，请参阅 创建 GitLab 升级计划。

补丁版本

补丁版本包括当前已发布的稳定 GitLab 版本的 错误修复，以及前两个月度版本和当前稳定版本的 安全修复。

制定这些政策的原因是：

  1. GitLab 有社区版和企业版，这使测试/发布软件所需的工作量翻倍。
  2. 向旧版本回溯会产生高昂的开发、质量保证和支持成本。
  3. 支持并行版本会阻碍增量升级，随着时间的推移，这些升级会累积复杂性，并为所有用户带来升级挑战。GitLab 有专门的团队确保增量升级（和安装）尽可能简单。
  4. GitLab 应用程序中的变更数量很大，这增加了向旧版本回溯的复杂性。在许多情况下，回溯必须经过与新变更相同的审查过程。
  5. 确保测试在旧版本上通过在某些情况下是一个相当大的挑战，因此非常耗时。

在补丁版本中包含新功能是不可能的，因为这会违反 语义化版本控制。 违反 语义化版本控制 对必须遵守各种内部要求（例如，组织合规性、验证新功能等）的用户有以下后果：

  1. 无法快速升级以利用补丁版本中包含的错误修复。
  2. 无法快速升级以利用补丁版本中包含的安全修复。
  3. 需要对稳定的 GitLab 版本以及每个补丁版本进行广泛测试的要求。

对于高度严重的安全问题，有 先例 将安全修复回溯到更早的 GitLab 版本。 此决定是逐案做出的。

在某些情况下，我们可能选择通过仅更新活动和当前稳定版本来使用常规月度发布流程解决漏洞，而不进行回溯。影响此决策的因素包括 利用的可能性非常低、漏洞的影响小、安全修复的复杂性以及对稳定性的最终风险。我们始终使用补丁版本来处理高和严重的安全问题。

回溯到旧版本

回溯到多个稳定版本通常保留给 安全修复。 然而，在某些情况下，根据错误的严重性，我们可能需要将错误修复回溯到多个稳定版本。

是否执行变更回溯的决定由 当前发布经理自行决定， 基于所有以下因素：

  1. 错误的估计严重性： 根据当前严重性定义，对用户的最高可能影响。
  2. 错误的估计优先级： 基于先前估计的严重性，对所有受影响用户的即时影响。
  3. 可能导致数据丢失和/或安全漏洞。
  4. 由于用户被证明无法升级到当前稳定版本，可能影响一个或多个战略账户。

如果满足上述列表中的所有项目，可以为当前稳定版本和前两个月度版本创建回溯版本。在极少数情况下，发布经理可能会例外，允许回溯到超过前两个月的版本。 例如，如果我们发布 13.2.1 并修复了在 13.0.0 中引入的严重错误，我们可以将修复回溯到新的 13.0.x 和 13.1.x 补丁版本。

严重性 3 及以下的请求会被自动拒绝。

要请求考虑回溯到多个稳定版本，请在 release/tasks 问题跟踪器中提出问题。

更多信息

您可能还想阅读我们的：