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.1112.012.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.1112.012.10 .
12.10.6 11.3.4 11.3.4 -> 11.11.8 -> 12.0.12 -> 12.10.6 需要两个中间版本: 11.1112.0
12.9.5 10.4.5 10.4.5 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.9.5 三个中间版本是必需的: 10.811.1112.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.510.811.1112.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.x11.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.

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