语义化版本控制

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

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

你可能感兴趣的:(前端,后端,java,ViewUI)