0. 前言
每个项目都有版本号，用来记录项目的更新，标识包的版本。语义化版本号是一套统一的规范，用来标准化版本号的定义。语义化版本控制 Semantic Versioning Specification又称Semver，是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立的。版本号的规范也不是一个新的概念，我们有时候也会看到类似这样的v1.1.2或Version.2.1 这样的版本号，这就不算是是规范要求的版本号。
下面我们就先简单介绍一下语义化版本号的规范要求。
1. 语义化版本号规则
当项目的依赖越来越多之后，如果我们的依赖没有一个标准规范的版本号控制，那么就有可能会出现，更新某个依赖之后突然就不能兼容项目了。版本控制就会越来越混乱。
语义化版本号定义格式为：
X.Y.Z（主版本号.次版本号.修订号）
以下几点是必须要注意的：
- 版本号必须以
X.Y.Z的格式编写，X、Y、Z 都必须是数字，且每一次更新都以数字递增，如：1.8.1 -> 1.8.2 -> 1.9.1 - 软件版本发布之后，不允许相同版本的再次更新。换句话说，就是如果有更新内容必须要修改版本号。
- 修订号（Z）指的的内部的问题修改，必须是向下兼容的内部错误修复，如果出现升级之后出现不兼容的问题，那么这个版本号就是有问题的。
- 次版本号（Y）指的是功能层面的调整，如果有新增功能，或者是老功能的下架，必须更新此版本号，当次版本号变化时，修订号（Z）需要置为0。需要注意的是，次版本号的升级也是需要向下兼容的。
- 主版本号（X），有任何不兼容的功能出现时必须更新主版本号，也可以是修订级别的改变。换句话说，不兼容的功能出现一定要更新主版本号，但是主版本号更新不一定不兼容。跟次版本一样，当主版本号更新时，修订号需要置0，当然次版本号也要置为0。
- 除了标准的版本号以外，还有一些先行版本号，类似
1.0.0-alpha,是在版本号之后用连字符拼接成的。常见的有alphabeta和rc，alphabeta没啥好讲的，大家应该都知道，rc是Release Candidate（候选版本）的缩写，表示功能不会再有添加，相当于预览版。
2. 语义化版本号优先级
语义化版本号是具有优先级的，这样在包管理识别时就可以判断那个版本的包是最新的。那么比较的时候具有下面几个规则：
- 首先最简单的当版本号都是标准的版本号时，将从大版本依次比较，如：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
3. 总结
以上就是语义化版本号控制的内容，其实很多人在平时开发的过程中都不在注意这个版本号的规范，当我们开发依赖或者一些工具包时，就需要重点关注一下。
下一篇我们将会展开讲讲，npm中是如何使用语义化版本控制的，并且如何利用语义化控制来进行包管理的。
