语义化版本控制

2019独角兽企业重金招聘Python工程师标准>>>

1. GNU 风格的版本号命名格式 :
    主版本号 . 子版本号 . 修正版本号 [-修饰词][. 先行版本号]
    Major_Version_Number.Minor_Version_Number.Revision_Number
    示例 : 1.2.1, 2.0, 5.0.0-alphal,2.1.8-alphal.1

1. 主版本号：第一个数字，产品改动较大，可能无法向后兼容（要看具体项目）
2. 子版本号：第二个数字，增加了新功能，向下兼容
3. 修正版本号：第三个数字，在release版本发布后修复 BUG 或优化代码，一般没有添加新功能，向下兼容
4. 修饰词：内部版本测试，例5.0.0-alphal
5. 先行版本号：一般内部版本测试升级，例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. 参考文献

• https://semver.org/lang/zh-CN/
• https://open.leancloud.cn/git-branch-guide/

转载于:https://my.oschina.net/winchell/blog/2045643