03. 项目版本号

我不相信造化弄人
世界上出类拔萃的人
都主动找寻他们想要的环境
要是遍寻不获
他们就创造一个
            ---萧伯纳 

既然我们都有 Build 号， 为什么还要版本号？在回答这个问题之前，首先我们需要明确版本号的作用。

如果我们开发的项目不需要任何其他的依赖，也没有其他人的项目依赖于我们，我个人觉得，完全可以不用版本号。当年还在学校读书时，刚学编程写的代码没有版本号也没事嘛。

显然，在实际工作中，结合历史经验教训，我们不能闭门造车。于是我们开始站在各种人（比如一个个体，一个小群体，一个组织，一个创业公司，一个国际巨头）的肩膀上，继续在软件的海洋中徜徉。随着开源项目的流行，渐渐地，大家发明了一个新词叫做依赖地狱，他给大家带来的效果就是每一次升级（不论大小）都是一场噩梦，牵一发而动全身。

因为很多第三方开源库对依赖的版本要求层次不齐，要么太松，要么太严。太严带来的问题就是升级一个它依赖的每一个可能都得升级，太松可能就会由于兼容性的问题带来一些意想不到的 Bug。

怎么办呢？有一个牛人站出来说，如果我们不采用一种正式的统一风格的版本号，那么我们的版本号将对依赖管理毫无意义。只有我们统一了版本号的风格，我们才能更方便的让使用我们开发的软件的用户了解我们升级版本号的意图。

他就是 Gravatars 的发明者，还是 Github 的联合创始人 Tom Preston-Werner。

Tom Preston-Werner

由于他本身长的也不丑，他的另一发明很快在全球最大的同性交友社区（Github）中流行起来：语义化版本，现在已经被翻译成22种语言了。

简而言之，版本号应该遵循这样一种统一的风格主版本号.次版本号.修订版本号（MAJOR.MINOR.PATCH）。并且按照如下规则升级：

1.  主版本号：当你做了不兼容的 API 修改；
2.  次版本号：当你做了向下兼容的功能性新增；
3.  修订版本号：当你做了向下兼容的问题修正，比如 bugfix。

另外，预览版本号及 Build 信息可以加到“主版本号.次版本号.修订版本号”的后面，作为延伸。

至于在实际项目中如何落地？语义化版本给我们到底传递了哪些信息？且听下回分解。