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

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

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

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

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

• Semantic Versioning

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

• 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 。

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

∎