GitLab release and maintenance policy · Gitlab 中文文档

# 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/) .