# GitLab release and maintenance policy

> 原文：[https://docs.gitlab.com/ee/policy/maintenance.html](https://docs.gitlab.com/ee/policy/maintenance.html)

*   [Versioning](#versioning)
*   [Upgrade recommendations](#upgrade-recommendations)
    *   [Upgrading major versions](#upgrading-major-versions)
    *   [Version 12 onward: Extra step for major upgrades](#version-12-onward-extra-step-for-major-upgrades)
    *   [Example upgrade paths](#example-upgrade-paths)
    *   [Upgrades from versions earlier than 8.12](#upgrades-from-versions-earlier-than-812)
    *   [Multi-step upgrade paths with GitLab all-in-one Linux package repository](#multi-step-upgrade-paths-with-gitlab-all-in-one-linux-package-repository)
*   [Patch releases](#patch-releases)
    *   [Backporting to older releases](#backporting-to-older-releases)
    *   [Security releases](#security-releases)
*   [More information](#more-information)

# GitLab release and maintenance policy[](#gitlab-release-and-maintenance-policy "Permalink")

GitLab 拥有严格的政策来管理版本命名，以及主要，次要，补丁和安全发布的发布速度. 新版本在[GitLab 博客](https://about.gitlab.com/releases/categories/releases/)上宣布.

我们目前的政策是：

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

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

## Versioning[](#versioning "Permalink")

GitLab 在其发行版中使用了[语义版本控制](https://semver.org/) ：（ `(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 | 对于向后兼容的错误修复程序，用于修复错误的行为. 请参阅[修补程序版本](#patch-releases) . | 如所须. |

## Upgrade recommendations[](#upgrade-recommendations "Permalink")

我们鼓励所有人运行[最新的稳定版，](https://about.gitlab.com/releases/categories/releases/)以确保您可以轻松升级到最安全，功能最丰富的 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 文档中找到](https://docs.gitlab.com/omnibus/update/README.html) .**注意：**有关在本地下载 Omnibus GitLab Linux 软件包以及[手动安装的](https://docs.gitlab.com/omnibus/manual_install.html)说明.

### Upgrading major versions[](#upgrading-major-versions "Permalink")

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

同样重要的是，在升级到新的主要版本之前，请确保所有后台迁移已完全完成. 要查看`background_migration`队列的当前大小， [请在升级前检查后台迁移](../update/README.html#checking-for-background-migrations-before-upgrading) .

如果您的 GitLab 实例具有与之关联的任何 GitLab Runner，则升级 GitLab Runners 以匹配已升级到的 GitLab 次要版本非常重要. 这是为了确保[与 GitLab 版本兼容](https://docs.gitlab.com/runner/) .

### Version 12 onward: Extra step for major upgrades[](#version-12-onward-extra-step-for-major-upgrades "Permalink")

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

为确保这些成功：

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

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

### Example upgrade paths[](#example-upgrade-paths "Permalink")

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[](#upgrades-from-versions-earlier-than-812 "Permalink")

*   `8.11.x`和更早版本：您可能必须先升级到`8.12.0`然后才能升级到`8.17.7` . 这是[在一个问题](https://gitlab.com/gitlab-org/gitlab/-/issues/207259)中[报道的](https://gitlab.com/gitlab-org/gitlab/-/issues/207259) .
*   [将 8.0](https://docs.gitlab.com/omnibus/update/README.html)合并到 GitLab 时， [CI 会在 8.0 版之前更改](https://docs.gitlab.com/omnibus/update/README.html) .

### Multi-step upgrade paths with GitLab all-in-one Linux package repository[](#multi-step-upgrade-paths-with-gitlab-all-in-one-linux-package-repository "Permalink")

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

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

Examples:

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

## Patch releases[](#patch-releases "Permalink")

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

制定这两项政策是因为：

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

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

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

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

### Backporting to older releases[](#backporting-to-older-releases "Permalink")

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

[当前版本管理者](https://about.gitlab.com/community/release-managers/)将决定是否执行向后移植更改，这与[管理 bug](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#managing-bugs)流程中所述类似，基于以下*所有条件* ：

1.  错误的估计[严重性](../development/contributing/issue_workflow.html#severity-labels) ：根据当前的严重性定义，对用户的最大影响.
2.  错误的估计[优先级](../development/contributing/issue_workflow.html#priority-labels) ：根据上述估计的严重性，立即对所有受影响的用户产生影响.
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](https://gitlab.com/gitlab-org/release/tasks/-/issues/new?issuable_template=Backporting-request) issue tracker.

### Security releases[](#security-releases "Permalink")

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

对于非常严重的安全问题， [有先例](https://about.gitlab.com/releases/2016/05/02/cve-2016-4340-patches/)将安全修复程序向后移植到 GitLab 的每月发布版本. 该决定是根据具体情况做出的.

## More information[](#more-information "Permalink")

Check [our release posts](https://about.gitlab.com/releases/categories/releases/).

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

*   升级过程中需要执行的步骤. 例如， [8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#upgrade-barometer)需要重新创建 Elasticsearch 索引. 任何较旧版本的 GitLab 升级到 8.12 或更高版本都需要此功能.
*   对我们支持的软件版本的更改，例如[在 GitLab 13 中不再支持 IE11](https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/#ending-support-for-internet-explorer-11) .

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

有关发行过程的更多信息，请参见我们的[发行文档](https://gitlab.com/gitlab-org/release/docs) . 您可能还需要阅读我们的《 [负责任的披露政策》](https://about.gitlab.com/security/disclosure/) .