博客搬家至此，原 blog： https://blog.csdn.net/chensanwa/article/details/106317776

1. 契约精神

什么是契约？

百度百科：https://baike.baidu.com/item/%E5%A5%91%E7%BA%A6/2874688

维基百科：https://zh.wikipedia.org/zh/%E5%A5%91%E7%BA%A6

相关概念：

• Design by Contract （契约式设计）

• Contract-First (契约先行)

2. 版本号

软件的版本号是如何定义的？- 知乎

3. 一方库版本设计

一方库：本工程中的各模块的相互依赖

推荐方案：

• 版本统一

• 顶层 pom 定义版本

• 子随父：child module 沿用 parent module 版本

版本管理：

Maven 项目，建议采用 Maven Version Plugin 统一管理升级。

发布：

无需发布，项目内引用。

4. 二方库版本设计

二方库：公司内部的依赖库，一般指公司内部的其他项目发布的 jar 包

推荐方案：

• 基于版本号，多版本发布

• 高版本向下兼容

发布：

Maven 私服发布，多版本代码发布。

4.1. 理解“高版本向下兼容”

• 对“修改、删除”关闭，对“新增”开放

旧版本：

{  "name":"Bob",  "age":20}

向下兼容新版本 - 新增

{  "name":"Alice",  "age":18,  "address":"Beijing"}

非向下兼容新版本 - 修改

{  "newName":"Alice",  "age":18}

非向下兼容新版本 - 删除

{  "age":18}

极端情况

如果整个契约变动很大，并不满足 “向下兼容”，建议新建 API，path 采用 v1, v2 等字样区分。

5. 三方库版本设计

三方库：公司之外的开源库， 比如 apache、ibm、google 等发布的依赖

推荐方案：

同二方库版本设计，需要更加注重版本，严格落实 “基于版本研发”。

发布：

Maven 私服 / 中央仓库 / Jar 包 多版本代码发布。

6. Web API 版本设计

背景：调用方多样性（H5 无版本、移动终端有版本），但通信协议一致。

推荐方案：

参考三方库版本设计

发布：

自建服务器发布，“伪多版本发布” （发行版为最新版本，向下兼容多版本）