1. GNU 风格的版本号命名格式 :
主版本号 . 子版本号 . 修正版本号 [-修饰词][. 先行版本号]
Major_Version_Number.Minor_Version_Number.Revision_Number
示例 : 1.2.1, 2.0, 5.0.0-alphal,2.1.8-alphal.1
- 主版本号:第一个数字,产品改动较大,可能无法向后兼容(要看具体项目)
- 子版本号:第二个数字,增加了新功能,向下兼容
- 修正版本号:第三个数字,在release版本发布后修复 BUG 或优化代码,一般没有添加新功能,向下兼容
- 修饰词:内部版本测试,例5.0.0-alphal
- 先行版本号:一般内部版本测试升级,例5.0.0-alphal.1
2. 版本号修饰词
- α(alphal) 内部测试版:
α版,此版本表示该软件仅仅是一个初步完成品,通常只在软件开发者内部交流,也有很少一部分发布给专业测试人员。一般而言,该版本软件的 bug 较多,普通用户最好不要安装。 - β(beta)外部测试版:
该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布,用户可从相关的站点下载。通过一些专业爱好者的测试,将结果反馈给开发者,开发者们再进行有针对性的修改。该版本也不适合一般用户安装。 - release 最终释放版:
该版本意味“最终释放版”,在出了一系列的测试版之后,终归会有一个正式版本,对于用户而言,购买该版本的软件绝对不会错。该版本有时也称为标准版。发布可以干脆不写。
3. 版本号管理策略
- 项目初始版本号可以是 1.0
- 项目进行 BUG 修正时,修正版本号加 1
- 项目增加部分功能时,子版本号加 1,修正版本号复位为 0
- 项目有重大修改时,主版本号加 1
4. 为什么要使用语义化版本控制
举个简单例子,例如一位新员工在使用tomcat-8.5.40开发部署包,在测试环境却不能运行,发现原因是因为新公司的测试环境与生产环境都是使用tomcat-6.0.45,解决办法是下载安装tomcat的主版本号为6就可以,不需要关心公司所使用tomcat对应的子版本号与修订版本号。
5. 规范
- 子版本号升级,旧接口有必要需要加@Deprecated注解
- 主版本号升级,必须清掉所有以前版本的@Deprecated接口与方法
- 标记版本号发布后,禁止修改该版本的内容,任何新修改要以新版本发布
- 如何修复已经发布的release版本中的缺陷。对应在有缺陷的tag分支bugfix,发布新版本并修正版本号加1,merge bugfix 到 master,这样做就不会影响master新功能的开发
6. 参考文献