关于软件版本命名的一些心得
在做软件开发的时候，对即将发布的版本进行命名是门学问。可能关于版本这点在一开始不是问题，但是后续随着交付的版本变多，就会发现版本是个大问题，如果命名不好，就会陷入「维护地狱」。
举几个在软件开发与交互过程中常用的场景：
- 我们发布了一个软件版本，但是此时马上发现这个刚刚发布的版本里面有一个必须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。
可以看到，上面的软件命名方法非常清晰，可以容纳一开始说的各种场景，并且版本的数字是累加的，前后顺序非常清晰。