当前位置: 首页 > article >正文

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组件 可以 实施破坏性变更,无论稳定级别如何。此时可以不设置过渡期。


http://www.kler.cn/a/589634.html

相关文章:

  • fastapi+angular实现个人博客
  • 什么是死锁?如何避免死锁?
  • 【spring boot 实现图片验证码 前后端】
  • ESP32学习 -从STM32工程架构进阶到ESP32架构
  • MySQL 性能优化:索引优化 + 读写分离 + Redis 缓存,TPS 提升 175% 实战解析
  • 《Classifier-Free Diffusion Guidance》的核心观点与方法
  • 三层架构与MVC架构的本质:从设计思想到实战选择
  • 贝叶斯网络的基本概念并构建一个贝叶斯网络(实例)
  • QT 磁盘文件 教程04-创建目录、删除目录、遍历目录
  • IntelliJ IDEA 中 Maven 的 `pom.xml` 变灰带横线?一文详解解决方法
  • 微服务即时通信系统---(八)用户管理子服务
  • 2025交易所开发突围:AI增强型撮合引擎与零知识证明跨链架构
  • 有趣的算法实践:整数反转与回文检测(Java实现)
  • java学习总结(六)Spring IOC
  • 基于k3s部署Nginx、MySQL、Golang和Redis的详细教程
  • 一键爬取b站视频
  • lua C语言api学习2 在C语言中使用lua语言
  • 3月17日作业
  • QT中的宏
  • JAVA | 聚焦 String 的常见用法与底层内存原理