ARTS(06)

1 Algorithm

2 Review

• Major 版本号表明发生的API不兼容的问题；
• Minor 版本号表明增加了一下向后兼容的操作；
• Patch 版本号表明做了一些向后兼容的bug修复。

在开发中，可都会依赖外部的 工具 或者库，但是过紧或者过松的版本依赖都会产生问题，因此在这里我们使用语义化版本管理可以避免这个问题。

2.1 详细说明

• 使用语义化版本的软件必须定义公共API，一旦API定义好，它就应该是准确和清晰明了的；
• 版本使用 X.Y.Z 形式， X , Y , Z 都是整数，也不能以 0 开头，每次版本更新都是自增的；
• 一旦某一个版本发布了，那么软件的内容将不能做任何改变，任何改变都要做新的版本发布；
• Major 版本号为0，也就是 0.y.z 表明是刚刚开始开发，随时都会变化，这时候的公共API都视为不稳定的；
• 版本 1.0.0 表明了公共的API；
• 只有向后兼容的bug修复必须增加 patch 版本号；
• 只有向后兼容的功能功能API发布必须增加 Minor 版本号；
• 当向后不兼容的公共API发布后必须增加 Major 版本号；
• 预发布版本可以在后面增加 [0-9A-Za-z-] 的标识符，预发布版本的优先级低于该版本号，通常表明该版本不保证满足兼容性要求，比如 1.0.0-alpha ；
• 元数据可以添加到版本号后面，用 + 连接，并且保证元数据满足 [0-9A-Za-z-] 要求，比如 1.0.0-beta+exp.sha.5114f85 ;
• 版本的优先级必须按照 Major , Minor , Patch 和 pre-release 划分开来，其中 元数据 不作为版本号比较，通常优先级比较从左到右；

2.2 为什么这么做

首先，使用语义化版本，可以很好的帮助我们软件的使用者，能够和用户达到很好的交流方式；再者使用语义化版本，可以帮我们约束我们软件开发的流程，如果控制我们软件的升级和兼容。

2.3 补充说明

• 任何时候以 0.1.0 作为软件开发的起点；
• 如果软件在生产环境中使用，那么以 1.0.0 开始；
• 如果软件每天都在快速开发，也就是公共 API 一直在改变，使用 major 为 0 ;
• 一旦更新 major 版本号，就需要考虑影响范围，需要在 cost/benifit 之间权衡；
• 为你的公共API提供更多的文档注释；
• 如果在更新 minor 版本号的时候，发现了不兼容现象，那么请立即增加 minor 版本号，然后恢复兼容性问题，并且通知用户改不兼容的版本号是有问题的；
• 如果我更新了我的软件依赖，但是不影响公共API，那么不需要更新 major 版本号；
• 如果想要废弃一些公共API，需要做两件事：（1）在公共文档中说明该公共API将会被废弃；（2）增加一个 minor 版本号，标明该API将会被废弃，以便在下一个 major 版本平滑过渡；

3 Tips

在使用 git 中的 reset 命令的时候，假设使用 --hard 参数后，版本将会回退到特定的 commit Id ，使用 git log 命令将不会显示该 commit id 后的所有提交，那么如果要查看之前的提交，可以使用 git reflog 命令查看最近的所有操作，找到先要恢复的 commit id ，使用 git checkout commitId , 将该提交切出来，注意目前的 HEAD 分支处于游离状态，需要使用 git checkout -b branch-name 将该游离的 HEAD 附属到 branch-name 分支上，待修复完毕后，从主分支上将其合并。

4 Share