• 配置弃用
  • 策略
  • 通知
  • 程序
    • 弃用配置
    • 移除配置
• 示例

{{< details >}}

• Tier: 基础版, 专业版, 旗舰版
• Offering: 私有化部署

{{< /details >}}

极狐 GitLab Linux 软件包附带许多不同的库和服务，为用户提供了丰富的配置选项。

随着库和服务的更新，它们的配置选项会发生变化并变得过时。为了提高可维护性并保持正常的设置，各种配置需要被移除。

配置弃用

策略

极狐 GitLab Linux 软件包至少保留 一个主要 版本的配置。我们无法保证弃用的配置在下一个主要版本中可用。有关更多详细信息，请参阅示例。

通知

如果配置变得过时，我们会通过以下方式宣布弃用：

1. 通过发布博客文章在 https://gitlab.cn/blog/。博客文章项目包含弃用通知以及目标移除日期。
2. 通过安装/重新配置输出（如果适用）。
3. 通过官方文档在 https://gitlab.cn/docs/。文档更新包含更正的语法（如果适用）或配置移除日期。

程序

本节列出了弃用和移除配置所需的步骤。

我们可以区分两种不同类型的配置：

1. 敏感的：可能导致重大服务中断的配置（如数据完整性、安装完整性或阻止用户访问安装）
2. 常规的：可能使某个功能不可用但仍使安装可用的配置（如默认项目/群组设置的更改或与其他组件的误通信）

我们还必须区分弃用和移除程序。

弃用配置

弃用程序对于 敏感 和 常规 配置是相似的。唯一的区别在于移除目标日期。

通用步骤：

1. 在 omnibus-gitlab 议题跟踪器 中创建议题，包含有关弃用类型和其他必要信息的详细信息。应用标签 deprecation。
2. 决定弃用配置的移除目标。
3. 为每个项目制定弃用通知，如通知部分所述。

移除目标：

对于常规配置，移除目标应该始终是 下一个主要 版本的日期。如果日期未知，您可以参考下一个主要版本。

对于敏感配置，情况会更复杂。如果下一个主要版本是两个次要版本之后，我们应该尽量不在 下一个主要 版本中移除敏感配置（这个数字是为了匹配我们的安全回溯发布政策而选择的）。

请参阅下表以获取一些示例：

移除配置

当弃用宣布并设置移除目标时，议题的里程碑应更改为与移除目标版本相匹配。

议题中的最终评论必须包含：

1. 发布博客文章部分的文本片段
2. 介绍更改的文档 MR（或片段）
3. 移除配置的草稿 MR 或必须完成的详细信息。

示例

用户配置在 /etc/gitlab/gitlab.rb 中可用，极狐 GitLab 版本 10.0 中引入了 gitlab_rails['configuration'] = true。在极狐 GitLab 版本 10.4.0 中，引入了一项新的更改，需要重命名此配置选项。新的配置选项是 gitlab_rails['better_configuration'] = true。开发团队将旧配置转换为新配置，并触发弃用程序。

这意味着这些两个配置选项在极狐 GitLab 版本 10 中有效。换句话说，如果您在极狐 GitLab 10.8.0 中仍然设置了 gitlab_rails['configuration'] = true，该功能将继续以与设置 gitlab_rails['better_configuration'] = true 相同的方式工作。然而，在安装/升级/重新配置运行结束时，设置旧版本的配置会打印出弃用通知。

在极狐 GitLab 11 中，gitlab_rails['configuration'] = true 不再有效，您必须手动将 /etc/gitlab/gitlab.rb 中的配置更改为新的有效配置。注意 如果此配置选项是敏感的并且可能危害安装或数据的完整性，则安装或升级将被中止。