|
1 | 1 | # 版本化
|
2 | 2 | 一个API服务可能提供多个API接口,API版本策略是应用在API 接口层面上而不是API服务层面上的。为了方便起见,下面所有的API均指API接口。
|
3 | 3 |
|
4 |
| -网络API应该使用语义化版本控制([Semantic Versioning](http://semver.org/))。对于某一个版本号`MAJOR.MINOR.PATCH`: |
| 4 | +网络API应该使用[语义化版本控制](http://semver.org/)。对于某一个版本号`MAJOR.MINOR.PATCH`: |
5 | 5 |
|
6 |
| -* 当你有不兼容的更改时,增加 `MAJOR`版本号。 |
7 |
| -* 当你以向后兼容的方式添加新的功能时,增加`MINOR`版本号。 |
8 |
| -* 当你修复了可以向后兼容的bug时,增加`PATCH`版本号。 |
| 6 | +* 当你有不兼容的更改时,增加 `MAJOR`版本号。 |
| 7 | +* 当你以向后兼容的方式添加新的功能时,增加`MINOR`版本号。 |
| 8 | +* 当你修复了可以向后兼容的bug时,增加`PATCH`版本号。 |
9 | 9 |
|
10 | 10 | 当API所处的版本不一样时,增加`MAJOR`版本的规则也会不一样:
|
11 | 11 |
|
12 |
| -* 对于API的第一个版本(v1),其`MAJOR`版本号应该加在proto包名称的末尾,例如`google.pubsub.v1`。如果在版本一时,API包含稳定的类型和接口,并且他们在未来也可能会保持不变,这时`MAJOR`版本号就可以被省略,不过这只是极少数的情况,例如`google.protobuf`和`google.longrunning`。 |
13 |
| -* 对于所有不是v1的版本,`MAJOR`版本号必须加在proto包的末尾,例如,`google.pubsub.v2`。 |
| 12 | +* 对于API的第一个版本(v1),其`MAJOR`版本号应该加在proto包名称的末尾,例如`google.pubsub.v1`。有一种极为罕见的情况`MAJOR`版本号就可以被省略,那就是API包含显而易见的稳定类型和结构,并且预计它不会有不兼容的改动,例如`google.protobuf`和`google.longrunning`。 |
| 13 | +* 对于所有不是v1的版本,`MAJOR`版本号必须加在proto包的末尾,例如,`google.pubsub.v2`。 |
14 | 14 |
|
15 | 15 | 对于pre-GA版本(如alpha和beta),我们推荐在其版本号后面加上一个相应的后缀。这个后缀应该由pre-release版本名称(例如 alpha,beta)和一个可选的pre-release版本号组成。
|
16 | 16 |
|
|
32 | 32 |
|
33 | 33 | 注:Google API平台目前没有原生支持`MINOR` 和`PATCH`版本号。每一个 `MAJOR`版本只有一套文档和客户端的库。API的作者需要通过文档和发布日志手动记录`MINOR`和`PATCH`版本号。
|
34 | 34 |
|
35 |
| -API新的主版本一定不能依赖于`这个API`先前的主版本。在了解了依赖性和稳定性风险后,API可以依赖于其他的API,不过一个稳定的API版本一定只能依赖于其他API最新的稳定版本。 |
| 35 | +一个API新的主版本一定不能依赖于先前主版本的相同API。在了解了依赖性和稳定性风险后,API可以依赖于其他的API,不过一个稳定的API版本一定只能依赖于其他API最新的稳定版本。 |
36 | 36 |
|
37 | 37 | 在某段时间内,相同API的不同版本必须能够同时在单个客户端中工作。这样才能帮助客户端从旧版API平滑迁移到新版API。
|
38 | 38 |
|
39 |
| -只有过了弃用期(deprecation period),旧的API版本才能被移除。 |
| 39 | +只有弃用期结束后,旧的API版本才能被移除。 |
40 | 40 |
|
41 |
| -在多个API中共享的通用稳定的数据类型,例如日期和时间等,应该定义在单独的proto包里面。如果有必要进行不兼容的修改,就必须引入带有新的类型名称或者新的包名称的`MAJOR`版本。 |
| 41 | +在多个API中共享的通用稳定的数据类型,例如日期和时间等,应该定义在单独的proto包里面。如果有必要进行不兼容的改动,就必须引入带有新的类型名称或者新的包名称的`MAJOR`版本。 |
42 | 42 |
|
43 | 43 | ## 向后兼容性
|
44 | 44 | 有时候很难去判断一个改变是否是向后兼容的。
|
45 | 45 |
|
46 |
| -下面列出了一些供你快速检索的类型,如果你有疑惑,可以点击查看[兼容页面](Compatibility.md)以获取更多的内容。 |
| 46 | +下面列出了一些供你快速检索的起点,如果你还有疑惑,可以点击查看[设计兼容页面](Compatibility.md)以获取更多的细节。 |
47 | 47 |
|
48 |
| -### 保持向后兼容的修改 |
| 48 | +### 保持向后兼容的改动 |
49 | 49 |
|
50 |
| -* 添加API接口到API服务 |
51 |
| -* 添加方法到API接口 |
52 |
| -* 添加HTTP绑定到方法 |
53 |
| -* 添加字段到请求消息 |
54 |
| -* 添加字段到响应消息 |
55 |
| -* 添加值到某个枚举类型 |
56 |
| -* 添加只输出(output-only)的资源字段 |
| 50 | +* 添加API接口到API服务 |
| 51 | +* 添加方法到API接口 |
| 52 | +* 添加HTTP绑定到方法 |
| 53 | +* 添加字段到请求消息 |
| 54 | +* 添加字段到响应消息 |
| 55 | +* 添加值到某个枚举类型 |
| 56 | +* 添加output-only的资源字段 |
57 | 57 |
|
58 |
| -### 不能向后兼容的修改 |
| 58 | +### 不能向后兼容的改动 |
59 | 59 |
|
60 |
| -* 删除/重命名服务、接口、字段名、方法或枚举值 |
61 |
| -* 修改 HTTP 绑定 |
62 |
| -* 修改字段类型 |
63 |
| -* 修改资源名的格式 |
64 |
| -* 修改已有请求的可见性(visible behavior) |
65 |
| -* 修改 HTTP定义中的URL 格式 |
66 |
| -* 在资源消息中添加读/写字段 |
| 60 | +* 删除/重命名服务、接口、字段名、方法或枚举值 |
| 61 | +* 修改HTTP绑定 |
| 62 | +* 修改字段类型 |
| 63 | +* 修改资源名的格式 |
| 64 | +* 修改已有请求的可见性 |
| 65 | +* 修改HTTP定义中的URL格式 |
| 66 | +* 在资源消息中添加读/写字段 |
0 commit comments