AIP-181 稳定级别
| 编号 | 181 |
|---|---|
| 原文链接 | AIP-181: Stability levels |
| 状态 | 批准 |
| 创建日期 | 2019-02-18 |
| 更新日期 | 2019-02-18 |
虽然不同组织（谷歌或其他组织）拥有不同的产品生命周期，AIP使用以下术语指代API组件 稳定性 。
注意 这些稳定级别大致对应于Google Cloud中的产品发布阶段（alpha、beta、GA），但并不完全相同。谷歌云计算平台在此基础上存在额外的期望和承诺。
Alpha
alpha 组件在一组已知的用户中进行快速迭代，这些用户 必须 能够容忍变化。用户群 应当 是经过筛选的、可管理的集合，以便能够与每个用户单独沟通。
在 alpha 组件 必须 允许并预期存在破坏性更高，用户 必须 不能对稳定性存在期望。
Beta
beta 组件 必须 是完整的，准备好发布为稳定版、接受公开测试。Beta组件 应当 向非特定（可能数量较多）用户发布。换句话说，beta组件 不应 设置许可名单， 应当 对公众开放。
因为beta组件用户对变化的容忍度较低，beta组件 应当 尽可能稳定。但是 必须 beta组件发生变更。这种变更 应当 是最小的， 可以 包含不向后兼容的变更。不向后兼容变更 必须 在合理的过渡期之后实施，给用户提供迁移代码的机会。过渡期 必须 在API被标记为beta时定义。
Beta组件 应当 有时间限制，如果在指定的时间范围内没有发现问题， 应当 提升到稳定级别。这个时间范围 应当 在API被标记为beta时设定。不同API的时间范围 可以 有所不同，但一个好的经验法则是90天。
稳定
稳定 组件 必须 在API主要版本的整个生命周期内得到完全的支持。由于用户期望稳定组件是稳定的，所以 必须 不能对组件进行破坏性变更，但以下所述情况除外。
主要版本
如果需要进行破坏性变更，API生产者 应当 创建API的下一个主要版本，并对现有版本设置废弃时间表。
要关闭包含稳定组件的版本， 必须 在API被标记为稳定时，定义正式的过程。这个过程 必须 为用户设定一个过度期，为他们提供合理的提前警告。
独立变更
在极少数情况下，如果只会给一小部分用户带来不便，可以进行小规模的、独立的破坏性更改。（创建新的主要版本会给所有用户带来不便。）此时API生产者 可以 将组件声明为废弃，但 必须 继续支持组件，直到稳定组件生命周期结束。
重要 对稳定API中进行破坏性变更是一种极端行为，应该作为与创建主要版本同等或更严重的行为。例如在谷歌，需要API治理团队批准。
紧急变更
在某些特殊情况下，如安全问题或法规要求，API组件 可以 实施破坏性变更，无论稳定级别如何。此时可以不设置过渡期。