Skip to content

Commit 5fb982e

Browse files
committed
update Versioning.md
1 parent 81efd63 commit 5fb982e

File tree

1 file changed

+26
-26
lines changed

1 file changed

+26
-26
lines changed

Versioning.md

Lines changed: 26 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,16 @@
11
# 版本化
22
一个API服务可能提供多个API接口,API版本策略是应用在API 接口层面上而不是API服务层面上的。为了方便起见,下面所有的API均指API接口。
33

4-
网络API应该使用语义化版本控制([Semantic Versioning](http://semver.org/)。对于某一个版本号`MAJOR.MINOR.PATCH`
4+
网络API应该使用[语义化版本控制](http://semver.org/)。对于某一个版本号`MAJOR.MINOR.PATCH`
55

6-
* 当你有不兼容的更改时,增加 `MAJOR`版本号。
7-
* 当你以向后兼容的方式添加新的功能时,增加`MINOR`版本号。
8-
* 当你修复了可以向后兼容的bug时,增加`PATCH`版本号。
6+
* 当你有不兼容的更改时,增加 `MAJOR`版本号。
7+
* 当你以向后兼容的方式添加新的功能时,增加`MINOR`版本号。
8+
* 当你修复了可以向后兼容的bug时,增加`PATCH`版本号。
99

1010
当API所处的版本不一样时,增加`MAJOR`版本的规则也会不一样:
1111

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`
1414

1515
对于pre-GA版本(如alpha和beta),我们推荐在其版本号后面加上一个相应的后缀。这个后缀应该由pre-release版本名称(例如 alpha,beta)和一个可选的pre-release版本号组成。
1616

@@ -32,35 +32,35 @@
3232

3333
注:Google API平台目前没有原生支持`MINOR``PATCH`版本号。每一个 `MAJOR`版本只有一套文档和客户端的库。API的作者需要通过文档和发布日志手动记录`MINOR``PATCH`版本号。
3434

35-
API新的主版本一定不能依赖于`这个API`先前的主版本。在了解了依赖性和稳定性风险后,API可以依赖于其他的API,不过一个稳定的API版本一定只能依赖于其他API最新的稳定版本。
35+
一个API新的主版本一定不能依赖于先前主版本的相同API。在了解了依赖性和稳定性风险后,API可以依赖于其他的API,不过一个稳定的API版本一定只能依赖于其他API最新的稳定版本。
3636

3737
在某段时间内,相同API的不同版本必须能够同时在单个客户端中工作。这样才能帮助客户端从旧版API平滑迁移到新版API。
3838

39-
只有过了弃用期(deprecation period),旧的API版本才能被移除。
39+
只有弃用期结束后,旧的API版本才能被移除。
4040

41-
在多个API中共享的通用稳定的数据类型,例如日期和时间等,应该定义在单独的proto包里面。如果有必要进行不兼容的修改,就必须引入带有新的类型名称或者新的包名称的`MAJOR`版本。
41+
在多个API中共享的通用稳定的数据类型,例如日期和时间等,应该定义在单独的proto包里面。如果有必要进行不兼容的改动,就必须引入带有新的类型名称或者新的包名称的`MAJOR`版本。
4242

4343
## 向后兼容性
4444
有时候很难去判断一个改变是否是向后兼容的。
4545

46-
下面列出了一些供你快速检索的类型,如果你有疑惑,可以点击查看[兼容页面](Compatibility.md)以获取更多的内容
46+
下面列出了一些供你快速检索的起点,如果你还有疑惑,可以点击查看[设计兼容页面](Compatibility.md)以获取更多的细节
4747

48-
### 保持向后兼容的修改
48+
### 保持向后兼容的改动
4949

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的资源字段
5757

58-
### 不能向后兼容的修改
58+
### 不能向后兼容的改动
5959

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

Comments
 (0)