GitLab release and maintenance policy

• Upgrade recommendations
  • Version 12 onward: Extra step for major upgrades
  • Upgrades from versions earlier than 8.12
• Patch releases
• More information

GitLab release and maintenance policy

GitLab 拥有严格的政策来管理版本命名，以及主要，次要，补丁和安全发布的发布速度. 新版本在GitLab 博客上宣布.

我们目前的政策是：

• 在任何给定时间， 仅针对当前稳定版本进行向后移植错误修复. （请参阅 .）
• 除了当前的稳定版本之外，还将安全修复程序反向移植到前两个月的版本中 . （请参阅安全性发布 .）

在极少数情况下，版本管理者可能会例外，并向后移植到最近两个月以上的版本. 有关更多信息，请参见 .

GitLab 在其发行版中使用了语义版本控制 ：（ .

例如，对于 GitLab 版本 12.10.6：

• 12代表主要版本. 主要版本是 12.0.0，但通常称为 12.0.
• 10代表次要版本. 次要版本为 12.10.0，但通常称为 12.10.
• 6代表补丁号码.

版本号的任何部分都可以递增为多个数字，例如 13.10.11.

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

我们鼓励所有人运行以确保您可以轻松升级到最安全，功能最丰富的 GitLab 体验. 为确保您可以轻松运行最新的稳定版本，我们正在努力使更新过程简单可靠.

如果您无法遵循我们的每月发布周期，则需要考虑几种情况.

在一个主要版本中的补丁版本和次要版本之间跳转是安全的. 例如，安全的是：

• 升级次要版本. 例如：

  • 12.7.5 -> 12.10.5
  • 11.3.4 -> 11.11.1
  • 10.6.6 -> 10.8.3
  • 11.3.4 -> 11.11.8
  • 10.6.6 -> 10.8.7
  • 9.2.3 -> 9.5.5
  • 8.9.4 -> 8.12.3
• • 12.0.4 -> 12.0.12
  • 11.11.1 -> 11.11.8
  • 10.6.3 -> 10.6.6
  • 11.11.1 -> 11.11.8
  • 9.5.5 -> 9.5.9
  • 8.9.2 -> 8.9.6

注意： Omnibus GitLab Linux 软件包中特定于版本的更改可在Omnibus GitLab 文档中找到 .注意：有关在本地下载 Omnibus GitLab Linux 软件包以及说明.

升级主要版本需要更多注意. 向后不兼容的更改和迁移保留用于主要版本. 我们不能保证主要版本之间的升级是无缝的. 我们建议在升级到下一个主要版本之前，先升级到主要版本中的最新可用次要版本. 这样做将解决所有向后不兼容的更改或弃用，以帮助确保成功升级到下一个主要版本.

同样重要的是，在升级到新的主要版本之前，请确保所有后台迁移已完全完成. 要查看background_migration队列的当前大小， 请在升级前检查后台迁移 .

如果您的 GitLab 实例具有与之关联的任何 GitLab Runner，则升级 GitLab Runners 以匹配已升级到的 GitLab 次要版本非常重要. 这是为了确保 .

Version 12 onward: Extra step for major upgrades

从版本 12 开始，还需要执行其他步骤. 在主要版本升级期间，可能会发生更重要的迁移.

为确保这些成功：

1. 在主要版本跳转期间递增到第一个次要版本（ x.0.x ）.
2. 继续升级到较新的版本.

例如： 11.5.x - > 11.11.x - > 12.0.x - > - > 13.0.x

Please see the table below for some examples:

Upgrades from versions earlier than 8.12

• 8.11.x和更早版本：您可能必须先升级到8.12.0然后才能升级到8.17.7 . 这是在一个问题中 .
• 将 8.0合并到 GitLab 时， .

Linux 软件包管理器默认安装用于安装和升级的软件包的最新可用版本. 对于需要多阶段升级路径的旧版 GitLab 版本，直接升级到最新的主要版本可能会出现问题.

当遵循跨多个版本的升级路径时，对于每次升级，请在软件包管理器的 install 或 upgrade 命令中指定所需的 GitLab 版本号.

Examples:

制定这两项政策是因为：

1. GitLab 拥有社区和企业发行版，使测试/发布软件所需的工作量加倍.
2. 向多个版本进行反向移植会产生很高的开发，质量保证和支持成本.
3. 支持并行版本不鼓励逐步升级，随着时间的推移，升级会越来越复杂，并给所有用户带来升级挑战. manbetx 客户端打不开有一个专门的团队，以确保增量升级（和安装）尽可能简单.
4. 在 GitLab 应用程序中创建的更改数量很多，这有助于将复杂性向后移植到较旧的版本. 在某些情况下，向后移植必须经过相同的审核过程，然后才能进行新的更改.
5. 在某些情况下，确保测试能够通过旧版本是一个相当大的挑战，因此非常耗时.

无法在补丁程序发行版中包含新功能，因为这会破坏语义版本控制 . 对于必须遵守各种内部要求（例如，组织合规性，验证新功能等）的用户，破坏具有以下后果：

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

如果战略用户需要在正式发布功能之前对其进行测试，我们可以提供创建包含特定功能的候选发布（RC）版本的功能. 仅在极端情况下才需要这样做，并且可以通过在发布/任务问题跟踪器中提出问题来请求考虑. 重要的是要注意，发布候选版本还将包含其他功能和更改，因为无法轻松隔离特定功能（如上所述的类似原因）. 候选发布版本与部署到 GitLab.com 或可公开访问的任何代码没有什么不同.

Backporting to older releases

向后移植到多个稳定版本通常是为安全版本保留的. 但是，在某些情况下，我们可能需要将错误修复程序回移植到多个稳定版本中，具体取决于错误的严重性.

将决定是否执行向后移植更改，这与管理 bug流程中所述类似，基于以下所有条件 ：

1. 错误的估计 ：根据当前的严重性定义，对用户的最大影响.
2. 错误的估计优先级 ：根据上述估计的严重性，立即对所有受影响的用户产生影响.
3. 潜在的数据丢失和/或安全漏洞.
4. 由于用户证明无法升级到当前的稳定版本，因此可能影响一个或多个战略帐户.

如果满足以上所有条件 ，则可以为当前的稳定版本和两个先前的每月版本创建反向版本. 在极少数情况下，发行经理可以授予例外，以向后移植到两个以上的先前每月发行中. 例如，如果我们发布11.2.1并包含11.0.0引入的严重错误的修复程序，则可以将该修复程序11.1.x移植到新的11.0.x和11.1.x补丁程序版本.

To request backporting to more than one stable release for consideration, raise an issue in the issue tracker.

安全版本是一种特殊的修补程序版本，除了当前的稳定版本之外，仅包括前两个月版本的安全修补程序和修补程序（请参见下文）.

对于非常严重的安全问题， 有先例将安全修复程序向后移植到 GitLab 的每月发布版本. 该决定是根据具体情况做出的.

Check .

每个月，我们都会发布 GitLab 的主要版本或次要版本. 在这些发行文章的末尾，有三个部分可供查找：弃用，删除和有关升级的重要说明. 这些将包括：

• 升级过程中需要执行的步骤. 例如， 8.12需要重新创建 Elasticsearch 索引. 任何较旧版本的 GitLab 升级到 8.12 或更高版本都需要此功能.
• 对我们支持的软件版本的更改，例如 .

有关发行过程的更多信息，请参见我们的发行文档 . 您可能还需要阅读我们的《 .