GitLab release and maintenance policy

原文：https://docs.gitlab.com/ee/policy/maintenance.html

GitLab release and maintenance policy

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

我们目前的政策是：

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

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

Versioning

GitLab 在其发行版中使用了语义版本控制 ：（ (Major).(Minor).(Patch) .

例如，对于 GitLab 版本 12.10.6：

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

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

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

版本类型 Description Cadence
Major 对于重大更改，或向公共 API 引入任何向后不兼容的更改时. 每年. 下一个主要版本是 2021 年 5 月 22 日的 GitLab 14.0.默认情况下，后续主要版本计划于每年 5 月 22 日发布.
Minor 当将新的向后兼容功能引入公共 API 时，将引入次要功能，或者推出一组较小的功能. 每月 22 日.
Patch 对于向后兼容的错误修复程序，用于修复错误的行为. 请参阅修补程序版本 . 如所须.

Upgrade recommendations

我们鼓励所有人运行最新的稳定版，以确保您可以轻松升级到最安全，功能最丰富的 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
    • 10.6.3 -> 10.6.6
    • 9.5.5 -> 9.5.9
    • 8.9.2 -> 8.9.6

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

Upgrading major versions

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

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

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

Version 12 onward: Extra step for major upgrades

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

为确保这些成功：

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

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

Example upgrade paths

Please see the table below for some examples:

目标版本 您的版本 推荐升级路径 Note
13.2.0 11.5.0 11.5.0 -> 11.11.8 -> 12.0.12 -> 12.10.6 -> 13.0.0 -> 13.2.0 四个中间版本是必需的：最终的11.11 ， 12.0和12.10的版本，再加上13.0 .
13.0.1 11.10.8 11.10.5 -> 11.11.8 -> 12.0.12 -> 12.10.6 -> 13.0.1 三个中间版本是必需的： 11.11 ， 12.0和12.10 .
12.10.6 11.3.4 11.3.4 -> 11.11.8 -> 12.0.12 -> 12.10.6 需要两个中间版本： 11.11和12.0
12.9.5 10.4.5 10.4.5 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.9.5 三个中间版本是必需的： 10.8 ， 11.11和12.0 ，然后12.9.5
12.2.5 9.2.6 9.2.6 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.2.5 四个中间版本是必需的： 9.5 ， 10.8 ， 11.11 ， 12.0 ，然后12.2 .
11.3.4 8.13.4 8.13.4 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.3.4 8.17.7是版本 8 的最新版本， 9.5.10是版本 9 的最新版本， 10.8.7是版本 10 的最新版本.

Upgrades from versions earlier than 8.12

Multi-step upgrade paths with GitLab all-in-one Linux package repository

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

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

Examples:

  1. # apt-get (Ubuntu/Debian)
  2. sudo apt-get upgrade gitlab-ee=12.0.12-ee.0
  3. # yum (RHEL/CentOS 6 and 7)
  4. yum install gitlab-ee-12.0.12-ee.0.el7
  5. # dnf (RHEL/CentOS 8)
  6. dnf install gitlab-ee-12.0.12-ee.0.el8
  7. # zypper (SUSE)
  8. zypper install gitlab-ee=12.0.12-ee.0

Patch releases

补丁程序发行版仅包含针对当前稳定发行版 GitLab 的错误修复 .

制定这两项政策是因为：

  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 release/tasks issue tracker.

Security releases

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

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

More information

Check our release posts.

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

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

You should check all the major and minor versions you’re passing over.

有关发行过程的更多信息，请参见我们的发行文档 . 您可能还需要阅读我们的《 负责任的披露政策》 .