Linux 软件包弃用策略

Linux 软件包附带了许多不同的库和服务，为用户提供了大量的配置选项。

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

配置弃用

策略

Linux 软件包会保留配置至少 一个主要 版本。我们无法保证已弃用的配置在下一个主要版本中仍然可用。更多详情请参见 示例。

公告

如果配置变得过时，我们将发布弃用公告：

• 通过 https://about.gitlab.com/blog/ 上的版本发布博客文章。博客文章中会包含弃用公告以及目标移除日期。
• 通过安装/重新配置的输出信息（如果适用）。
• 通过 https://docs.gitlab.com/ 上的官方文档。文档更新会包含修正后的语法（如果适用）或配置的移除日期。

流程

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

我们可以将配置分为两种不同类型：

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

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

弃用配置

弃用流程对于 敏感 和 常规 配置来说基本相同。唯一的区别在于目标移除日期。

通用步骤：

1. 在 omnibus-gitlab 问题跟踪器中创建一个 issue，详细说明弃用类型和其他必要信息。并应用 deprecation 标签。
2. 确定已弃用配置的移除目标
3. 按照 公告部分 中的说明，为每个项目制定弃用公告

移除目标：

对于常规配置，移除目标应始终为 下一个主要 版本的发布日期。如果日期未知，可以引用下一个主要版本号。

对于敏感配置，情况会稍微复杂一些。如果下一个主要版本距离当前版本有 2 个次要版本，我们应避免在下一个主要版本中移除敏感配置（选择此数字是为了与我们的安全补丁发布策略保持一致）。

请参见下表中的示例：

移除配置

当弃用公告已发布且移除目标已设定后，该 issue 的里程碑应更改为与移除目标版本相匹配。

该 issue 的最终评论必须包含：

• 版本发布博客文章部分的文本片段。
• 指向引入此变更的文档合并请求（或文档片段）的链接。
• 二者之一：
  • 指向移除该配置的草稿合并请求的链接。
  • 必须完成的工作的详细信息。

示例

在 GitLab 10.0 版本中，引入了位于 /etc/gitlab/gitlab.rb 的用户配置 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 中的配置更改为新的有效配置。 注意：如果此配置选项是敏感的，并且可能危及安装实例或数据的完整性，那么安装或升级过程将会被中止。