版本控制

    网络API应该使用。比如给定版本号 :

    1. 当做出不兼容修改的时候,修改 MAJOR 版本号
    2. 当以向后兼容的方式添加功能时,修改 版本号
    3. 当进行向后兼容的错误修复时,修改 PATCH 版本号

    根据 API 版本,指定主要版本号(major version number)时可使用不同的规则:

    • 对于v1之外的所有版本的 API,主版本号必须编码进原包名中。例如,google.pubsub.v2

    对于 GA 之前的版本,例如 alpha 和 beta,建议在版本号后面附加一个后缀,应该包括预发布版本名称(例如alpha,beta)和预发布版本号。

    minor 和 patch 版本号应该反映在 API 配置和文档中,它们不允许被编码在原始程序包名称中。

    注意:One Platform目前不支持 minor 和 patch 版本。 API 所有者需要通过 API 文档和发行说明记录它们。

    API 的新 major 版本不能依赖于以前同样API的主要版本。 API 在了解相关的依赖性和稳定性风险的情况下可以依赖其他 API。 API 必须只依赖于其他API的最新稳定版本。

    旧的 API 版本应该在其弃用期结束后删除。

    由许多 API 共享的公用而稳定的数据类型,例如日期和时间,应该在单独的 proto 包中定义。如果需要进行中断更改,则必须引入新类型名称或具有新的主要版本的包名称。

    确定向后兼容的修改是困难的。

    • 将 API 接口添加到 API 服务定义
    • 向 API 接口添加方法
    • 向方法添加 HTTP 绑定
    • 向请求消息中添加字段
    • 向响应消息中添加字段
    • 添加仅输出的资源字段

    向后不兼容的修改

    • 删除或重命名服务,字段,方法或枚举值
    • 更改 HTTP 绑定
    • 更改字段的类型
    • 更改资源命名格式
    • 更改现有请求的可见行为
    • 向资源消息添加读/写字段