1.3. API 弃用策略
红帽构建的 MicroShift 由来自许多上游社区提供的许多组件组成。因此，我们预计许多组件、关联的 API 接口和关联的功能集合将随着时间推移而有所变化，并且在功能被完成删除前会提供一个弃用的阶段。
1.3.1. 弃用的 API 部分
红帽构建的 MicroShift 是一个分布式系统，多个组件通过一组结构化 API 与由集群 control plane 管理的共享状态交互。根据 Kubernetes 惯例，红帽构建的 MicroShift 提供的每个 API 与组标识符相关联，每个 API 组都独立版本控制。每个 API 组都在不同的上游社区中管理，包括 Kubernetes、Metal3、Multus、Operator Framework、Open Cluster Management、OpenShift 本身等。
虽然每个上游社区可能会为给定的 API 组和版本定义自己的唯一弃用策略，但红帽会将社区特定策略规范化为之前定义的兼容性级别之一，具体取决于我们的集成和认知，以简化最终用户消费和支持。
API 的弃用策略和调度因兼容性级别而异。
弃用策略涵盖 API 的所有元素，包括：
- REST 资源，也称为 API 对象
- REST 资源的字段
- REST 资源的注解，不包括特定于版本的限定符
- Enumerated 或 constant 值
除每个组中最新的 API 版本外，在宣布弃用后，必须支持旧的 API 版本，且时间不少于：
| API 层 | Duration |
|---|---|
| 1 级 | 在一个主版本内是稳定的。它们在主版本中可能被弃用，但在后续的主发行版本前不会删除它们。 |
| 2 级 | 从公布弃用后的 9 个月或 3 个发行版本（以更长的时间为准）。 |
| 3 级 | 请参阅特定于组件的调度。 |
| 4 级 | 无。无法保证兼容性。 |
以下规则适用于所有 1 级 API：
- API 元素只能通过递增组版本来删除。
- API 对象必须能够在没有信息丢失的情况下在 API 版本之间往返，除非整个 REST 资源在某些版本中不存在。如果在版本之间没有对等的字段，数据将在转换过程中以注解的形式保留。
- 一个特定组中的 API 版本在新的 API 版本至少发行了一个稳定的版本前不会被弃用，除非整个 API 对象已被删除。
1.3.2. 弃用的 CLI 元素
对于面向客户端的 CLI 命令，它们的版本模式与 API 不同，它们是面向用户的组件系统。用户与 CLI 交互的两种主要方法是通过命令或标志（在此上下文中称为 CLI 元素）。
除非另有说明，否则所有 CLI 元素都默认为 API 层 1，除非另有说明或 CLI 依赖于较低层 API。
| 元素 | API 层 | |
|---|---|---|
| 正式发布(GA) | 标志和命令 | 1 级 |
| 技术预览 | 标志和命令 | 3 级 |
| 开发者预览 | 标志和命令 | 4 级 |
1.3.3. 弃用整个组件
弃用整个组件的持续时间和调度直接映射到与该组件公开的 API 的最高 API 层关联的持续时间。例如，在满足第 1 层弃用计划前，无法删除带有级别 1 和 2 的 API 的组件。
| API 层 | Duration |
|---|---|
| 1 级 | 在一个主版本内是稳定的。它们在主版本中可能被弃用，但在后续的主发行版本前不会删除它们。 |
| 2 级 | 从公布弃用后的 9 个月或 3 个发行版本（以更长的时间为准）。 |
| 3 级 | 请参阅特定于组件的调度。 |
| 4 级 | 无。无法保证兼容性。 |
