关于软件版本命名的一些心得

栏目: 服务器 · 发布时间: 5年前

内容简介:在做软件开发的时候,对即将发布的版本进行命名是门学问。可能关于版本这点在一开始不是问题,但是后续随着交付的版本变多,就会发现版本是个大问题,如果命名不好,就会陷入「维护地狱」。举几个在软件开发与交互过程中常用的场景:针对以上的场景,有各种各样的版本命名方案,可以容纳上面的各种场景。但是在这篇文章里,我想推荐的是osgi推出的命名标准,因为osgi的版本命名标准简单直接可靠,用起来也比较省心。osgi的版本命名标准在这里:

在做软件开发的时候,对即将发布的版本进行命名是门学问。可能关于版本这点在一开始不是问题,但是后续随着交付的版本变多,就会发现版本是个大问题,如果命名不好,就会陷入「维护地狱」。

举几个在软件开发与交互过程中常用的场景:

  • 我们发布了一个软件版本,但是此时马上发现这个刚刚发布的版本里面有一个必须fix的bug,所以不得不马上打个补丁,再马上发个新版本。
  • 我们需要重写整个架构,但是之前的架构已经卖给了好多客户,卖出去了很多拷贝,所以还要继续维护之前的旧的架构,并且使用旧版本的用户提交过来的bug也要持续在旧版本上进行fix。
  • 针对前一版本,我们修复了一波bug,但是功能特性并没有大的变化,此时只想发布一个补丁修复版。
  • 产品开发的流程中,先build出一个工程版本,用于内部测试,然后迭代数次,感觉比较稳定了,再fix几轮bug,提交给测试几轮,作为代发布版本,最后发布交付给用户的最终版。

针对以上的场景,有各种各样的版本命名方案,可以容纳上面的各种场景。但是在这篇文章里,我想推荐的是osgi推出的命名标准,因为osgi的版本命名标准简单直接可靠,用起来也比较省心。osgi的版本命名标准在这里:

关于软件版本命名的一些心得

简单总结下,它所规定的版本号包含四部分:

  • major
  • minor
  • micro
  • qualifier

关于这四部分的说明:

  • major ➞ a breaking change
  • minor ➞ a backward compatible changes
  • micro ➞ a bug fix (no API change)
  • qualifier ➞ a new build

可以看到,使用osgi的版本命名方式,维护软件的不同版本变得非常简单直接:

  • 当我们想要快速rebuild并交付一个新版本的时候(有时候可能只是几行代码的修改),就增加 qualifier 的数字。比如: 0.0.0.1 -> 0.0.0.2
  • 当我们要简单修复一波bug,交付一个新版本的时候,就增加 micro 的数字。比如: 0.0.1.10 -> 0.0.2.1
  • 当我们修复了好几波bug fix,发布了好几个 micro 版本,此时 micro 版本的数字已经累加到一定程度,就把 minor 加一。比如: 0.0.12.13 -> 0.1.0.0
  • 当我们要对前一版软件做重大功能变更,改进,并且不在兼容旧版本的时候,就增加 major 主要版本。比如: 0.1.2.3 -> 1.0.0.0

可以看到,上面的软件命名方法非常清晰,可以容纳一开始说的各种场景,并且版本的数字是累加的,前后顺序非常清晰。


以上所述就是小编给大家介绍的《关于软件版本命名的一些心得》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

PHP5与MySQL5 Web开发技术详解

PHP5与MySQL5 Web开发技术详解

杜江 / 电子工业出版社 / 2007-11 / 79.00元

《PHP5与MySQL5 Web开发技术详解》(含光盘)是目前中文版本第一个真正介绍PHP5及MYSQL5新增语法与功能的权威宝典!一起来看看 《PHP5与MySQL5 Web开发技术详解》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

html转js在线工具
html转js在线工具

html转js在线工具