软件版本号
版本控制的好处是不言而喻的，在版本控制中对版本号的使用（比如打TAG）其实也是一门学问，如何科学地使用版本号呢？
目前有很多软件版本号系统，我就来介绍一下常用的几种吧～
##Semantic Versioning（语义化版本）##
这种版本号系统在维基百科中被划分为“Degree of compatibility（兼容度）”类型的版本号系统，使用三个整数来表示向后兼容性程度，格式为MAJOR.MINOR.PATCH：
- MAJOR（重大） 在API上，此位版本号和此位前一个版本号完全不兼容，如3.0.0的API完全不兼容2.0.0的请求；
- MINOR（轻微） 此位版本号表示新添加了一个公能，且保持旧功能完全向后兼容；
- PATCH（修补） 此位版本号表示修复了以前功能的BUG，且完全向后兼容。
这种版本号系统允许添加一些标签作为扩展，如1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92，这些都是OK的。
mongoose在4.0新版本表明要使用这种版本号系统。
从一般的产品开发角度上来说，个人感觉这种最好，因为一般产品的用户对版本号的关注和依赖并不高，对开发人员来说这种版本号控制方式恰好就是开发的控制方式，非常方便。
##Odd/Even versioning（奇偶版本）##
同样是三个整数组成的版本号系统，格式为A.B.C，A代表主版本号，B代表次主版本号，C代表较小的末版本号。只有在内核发生很大变化时，A才变化。可以通过数字B来判断软件是否稳定，偶数的B代表稳定版，奇数的B代表开发版。C代表一些bug修复，安全更新，新特性等的次数。以版本2.4.0为例，2代表主版本号，4代表次版本号，0代表改动较小的末版本号。在版本号中，序号的第二位为偶数的版本表明这是一个可以使用的稳定版本，如2.2.5，而序号的第二位为奇数的版本一般有一些新的东西加入，是个不一定很稳定的测试版本，如2.3.1。这样稳定版本来源于上一个测试版升级版本号，而一个稳定版本发展到完全成熟后就不再发展。
Linux Kernel曾经很长一段时间使用这种版本号系统，后来计划使用类似于Semantic Versioning的版本号系统。
NodeJS和MongoDB都在使用这种版本号系统，由于在版本号系统中强化了软件稳定与非稳定的信息，所以这种版本号很好地适用于用户对版本号和稳定性要求较高的情况，如比较重要的商业软件，再如专供于再开发或被用于开发其他软件的软件或程序库。