GitLab基础：版本升级策略与注意事项

截止到2020年8月22号，GitLab已经发布了13.3的版本，这篇文章整理一下GitLab的版本策略和升级方式。

版本与发布

GitLab对于版本的命令有着严格的策略，同时对于发布的节奏也有控制，对于大版本（major）、小版本（minor）、修订（patch以及安全相关）等的发布都会在如下地址进行公开宣布：

• https://about.gitlab.com/releases/categories/releases/

发布策略

当下GitLab的发布策略主要包括：

• Backporting方式（将修正的内容合到之前的旧版中）的bug修正只限于当前稳定版本的发布。
• Backporting方式的安全相关的修正只限于当前稳定版本以及此版本前两个月内发布的版本。
• Backporting方式很少做超过两个月以上的内容合并

解读：版本发行很快，用户量很大，对于发现的bug修正即使是安全性相关的对之前所有的版本进行合并显然是不现实的，对于用户来说，在稳定和安全以及特性三这之间做平衡的时候，现在还需要考虑的发布策略所带来的风险了，这个对于稳定性和安全有所不利，换句话说，如果不及时升级版本或者选择了非稳定性的版本，存在安全性的修正不能得到及时修正的风险。

版本说明

GitLab遵循语义化版本进行管理，对于发布的版本格式如下所示：

版本格式：主版本号.次版本号.修订号

以GitLab 12.10.5为例进行如下说明：

• 12为主版本号，主版本的发布为12.0.0，但是很多时候引用的时称为12.0.
• 10为次版本号，次版本号为12.10.0，引用的时候多称为12.10.
• 5表示修订版本号

详细语义化版本介绍，可参看：

• https://liumiaocn.blog.csdn.net/article/details/108140914

发布节奏 版本类型 发布场景 发布节奏 主版本号 重大变更或者不向下兼容的情况出现时 每年发布一个大版本，下次主版本号发布将于2021年5月22号，发布GitLab 14.0，后续也缺省每年5月22号发布新版。 次版本号 新的向下兼容的一个或者多个小的功能特性增强 每月发布一个小版本，缺省在每月22号 修订版本号 向下兼容的bug修正 根据需要，在任何时候都可以进行 版本升级：次版本和修订版本

GitLab建议用户使用最新的稳定版本，从而能够更加安全，同时也能够使用更丰富的特性。对于无法跟上每月发布节奏的用户，提供了如下的升级策略：

建议1: 使用最新稳定版本

建议2: 在次版本号和修订版本号都发生变化的时候，升级先保证主版本号相同：

• 升级次版本号的例子： 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

版本升级：升级主版本

升级主版本需要额外留意，向下不兼容的变更和移值多被保留到主版本号更新的时候，所以主版本的更新GitLab是无法保证完全一帆风顺的。首先有如下建议：

建议3: 升级主版本之前先将次版本和修订版本升级成离主版本号最近的版本，这样在升级主版本的时候可以定位问题的发生到底是向后不兼容的问题还是次版本号升级所引起的。

建议4: 如果GitLab有关联的GitLab Runner，GitLab Runner也需要升级为匹配的相应版本。

版本升级：主版本号升级至12及之后

升级至版本12以及之后，在主版本升级的时候可能需要“多级跳”来确保升级的成功，在主版本升级的时候，先行升至早期的x.0.x版本，然后进行继续升级，比如：11.5.x -> 11.11.x -> 12.0.x -> 12.10.x -> 13.0.x

参考内容

https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations