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

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

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

  • 我们发布了一个软件版本,但是此时马上发现这个刚刚发布的版本里面有一个必须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

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

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章