弃用术语

弃用

• 在停止支持或移除功能之前是必需的。
• 不推荐使用该功能。
• 开发仅限于优先级1/严重性1的错误修复。
• 将在未来的主要版本中移除。
• 在宣布了停止支持或移除日期的弃用公告后开始。
• 在停止支持日期或移除日期过后结束。

停止支持

• 移除前的可选步骤。
• 强烈不建议使用该功能。
• 不提供支持或修复。
• 内部不再进行测试。
• 将在未来的主要版本中移除。
• 在停止支持日期过后开始。

宣布停止支持期 仅应在特殊情况下使用，不建议常规使用。 大多数功能应该先弃用，然后移除。

移除

• 无法使用该功能。
• 功能不再受支持（如果尚未宣布停止支持期）。
• 根据我们的 语义版本控制策略 在主要版本中发生。
• 在移除日期过后开始。

破坏性变更

如果客户需要采取措施确保其 GitLab 工作流程不被中断，则任何变更都算作破坏性变更。

破坏性变更可能来自以下来源：

• 有意的产品变更
• 配置更新
• 第三方弃用

默认情况下，不允许破坏性变更，除非破坏性变更实施计划已获得领导层批准。

第三方依赖

本节适用于所有前面的术语。

第三方依赖中的变更（弃用、停止支持、移除或破坏性变更）与 GitLab 本身功能的变更分开处理：

• 这些变更遵循依赖项自身的生命周期，不受 GitLab 功能流程和时间线要求的约束。
• GitLab 将尽量减少影响，并为影响我们产品的第三方依赖变更提供平滑的迁移体验。
• 必要时，依赖项的安全更新可能会在不遵循其标准弃用流程的情况下应用，以解决漏洞解决 SLA 内的严重漏洞。更多信息请参阅 GitLab Handbook。
• 在依赖项变更超出我们控制或时间线的情况下，GitLab 可能需要在我们的常规流程和时间线之外对我们自己的软件进行变更，以 维护我们的功能、兼容性或安全性。
• GitLab 将尽合理努力传达重要的第三方依赖变更。
• GitLab 不对 GitLab 产品未直接使用的第三方依赖功能中的任何变更负责。
• 利用这些第三方依赖超出 GitLab 使用模式的客户自行承担风险，并且应该：
  • 独立监控第三方的发布说明。
  • 针对新的依赖版本测试其自定义实现。
  • 为其第三方变更规划自己的迁移策略。