每次打开谷歌浏览器的About页面更新的时候，总是期待着一个新版本的到来，新的东西总是让人感到Amazing。这样久了之后心中不免产生一个疑问，什么时候该发布一个新版本了，有什么规律么？平时的小更新总是版本号后面无关仅要的数字的增长，当这个数字增长到何时可以让主版本号加1？

带着这个疑惑到StackOverflow造访了一下，良久无回音。再加上自己写点小东西时也需要正确地命名版本号来管理发布，看来是有必要补充一下这方面的知识了。

语义化版本号

当我在发布jQuery插件时，发现其官方页面上提供了一个帮助我们更好地命名软件版本号的概念"semver"，即Semantic Versioning语义化的版本。看了下其规则觉得很nice。

关于软件的版本号，向来没有统一或者严格的规定，对于大型软件产品，其开发团队内部或许维护了自己的一套规则来界定软件开发到何时可以发布新版本，何时又只是增加次版本号，也或许在遵循一些现成的大家认可的规范；更多情况是对个人开发者而言，在自己捣腾一些小东西时，这样的版本号规则就更自由了，完全视软件作者的水平而良莠不齐。有的作者或许学习过版本相关的知识，知道遵循一些现成的规范，更多的新手比如像我这样，完全是随毫无规则地在使用版本号。今天开发完一个功能，那就发布一个版本叫做0.1吧，下午发现个bug并修复之再发个版本0.2吧。如此显然不好，无规矩不成方圆啊，我们已经饱受各浏览器不完全遵循W3C规范而带来的各种跨浏览器前端问题了，血的教训，历史告诉我们，不能让悲剧重演，所以迫切需要一个好的准则来指导大家更好地使用软件版本号。

语义化版本号的作者正是抱着这样的希望创造了它。

语义化版本号是由Tom Preston-Werner 发起的一个关于软件版本号的命名规范，关于这个规范详细的说明可以在官网查看，也可访问其GitHub项目页面，而关于该规范的中文版本，可以访问我fork的版本，由官网繁体中文转换而来，并稍加修改以更符合大陆用语。顺便提句，该规范的作者是Gravatars创办者同时是GitHub联合创始人。你或许不知道gravatar但作为程序员你肯定知道GitHub。

基本规则

顾名思义，语义化的版本就是让版本号更具语义化，可以传达出关于软件本身的一些重要信息而不只是简单的一串数字。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

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

先行版（预览版）版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面，作为延伸。

具体规范

具体详尽的规范可以参见其官网，当然也可以访问中文版本。这里简单总结一下。

• 版本号是以点隔开的形式'X.Y.Z' 且XYZ为正整数，数字前面不加0， 也就是说v0.1.0不能写成v0.01.0
• 一般软件开发过程中以0.1.0 版本开始，开发过程中不断增加新功能，则增加次版本号比如变成0.2.0，然后期间的问题及bug修复体现在修订号上，比如版本号变成0.1.12。这一阶段的版本视为不稳定版本，一般也未对外发布
• 主版本号表示正式版的形成，也即如果你开发的是供大家使用的软件或插件，那就标致本软件公共API的形成，比如新浪微博API v1.0.0发布，大家就可以在自己网站上调用了，这是个正式而稳定的版本。所以这里有个规定，版本一旦发布，不允许对软件做任何修改。任何改过之后的代码都应标记新的版本号在下次发布中体现
• 主版本号的增加可以是次版本号以有修订号增加到一定数量后的结果，也可以是有不兼容旧版的新功能或API加入的结果，并且主版本增加后次版本号和修订号归零
• 次版本号表示有兼容旧版本的功能或API增加，而修订号表示bug修复并且这种修复一般是对代码结果不正确的修复而且一定是兼容旧版本的，如果你修复bug越改越大结果不兼容旧版本了，则需要增加主版本号
• 其他信息比如预览版，先行版或者软件编译信息可以跟随在修订号之后。示例：1.0.0-alpha+001、1.0.0+20130313144700、 1.0.0-beta+exp.sha.5114f85

使用语义化版本号的好处

也即原规范中对为何要使用语义化版本号的描述。在我看来，无非就是在遵循了本规范后，透过版本号，你可以非常清楚地了解到你手头拿到的软件版本相比于上一个版本发生了怎样的变化，所以你在使用的时候可以更注意一下这些变化，以免出现不兼容的情况。

比如如果主版本号升级了，可以知道软件新增了功能且该功能或者重大问题修复，且都是与旧版本不兼容的。好比大家热切推崇的文本编辑器Sublimetext2和3，他的很多插件在这两个版本间无法兼容使用，所以一般要标明插件是使用在Sublimetext2还是3中。同时主版本号的更新也可以表明是次版本号更新到了一定程序，比如新增功能数量达到了一定指标，我们可以认为可以升级一下主版本号了，毕竟一个可以copy as rtf，带项目文件管理sidebar，更换主题的文本编辑器和Windows自带文本编辑器在功能上还是有质的区别的。

如果次版本更新了，我们可以知道有小部分新功能添加，或者修订号更新，有小部分bug被修复，而在获取这些信息时完全还没有查看change log。这正是语义化的好处，版本号就告诉你大部分信息了，当然更具体的参见change log吧。

另外个好处就是当大家都在遵循一个规范的时候，无疑扫清了一些认知上的障碍，将事情简单化，大家也心照不宣地能看懂每个人代码中的版本号的意思，初学者也很容易掌握这方面的知识。

一些问题

各版本优先级

也即如何判定哪个版本版次更高。下面是来自原规范的解释，已经够详尽就不另外阐述。

判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译信息不在这份比较的列表中）。由左到右依序比较每个标识符号，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须透过由左到右的每个被句点分隔的标识符号来比较，直到找到一个差异值后决定：只有数字的标识符号以数值高低比较，有字母或连接号时则逐字以ASCII的排序来比较。数字的标识符号比非数字的标识符号优先层级低。若开头的标识符号都相同时，栏 ​​位比较多的先行版本号优先层级比较高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0- rc.1 < 1.0.0。

如何界定正式版1.0.0的发布

这个正是我在开发自己的jQuery插件时面临的问题。如上面规范所述，软件最初开发阶段一般以0.1.0开始。当软件基本正式功能全部完成且测试通过，对外公共API完成可以用于实际线上环境了，则可以形成1.0.0的正式版了。

更多关于本规范的常见问题还是请查看文档，上面的FAQ列出的问题很实在，可以解决使用本版本号命名中的疑惑。

Reference:

• Semver 简体中文版本：https://github.com/Wayou/semver_zh_CN/blob/master/semver_zh_CN.md
• Semver GitHub项目地址：https://github.com/mojombo/semver
• semver 官方文档页：http://semver.org/