语义化版本号规范

作为前端，经常在项目中安装各种依赖，依赖的版本号代表着什么意思一直不太明白，所以本篇系统化学习一下。

Semver简介

在开发早起，我们安装某个软件包时，会发现这个软件包又依赖了不同版本的其他软件包，随着依赖的软件包越来越多，依赖的关系也越来越深，这个时候可能面临版本控制被锁死的风险，这就是【依赖地域】的问题。

因此，Github起草了一个具有指导意义的，同意的版本号表示规则，称为Semantic Versioning语义化版本，即Semver，目前由npm的团队维护。

Semver的出现，规定了版本号如何表示，如何增加，如何进行比较，不同的版本号意味着什么。

版本格式

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

• 主版本号（major）：当新增或者修改了不兼容的API，每当主版本号递增时，次版本号和修订号必须归零。
• 次版本号（minor）：当做了向下兼容的功能性新增和修改，开发中有个不成文的规定，偶数为稳定版本，奇数为开发版本，每当次版本号递增时，修订号必须归零。
• 修订号（patch）：当做了向下兼容的问题修正，即Bug的修复。

比如：V1.2.3是一个语义化的版本号，版本号中的每个数字的具体含义为：

先行版本

如果需要增加先行版本号和编译数据，则需要将现行版本号（pre-release）和版本编译数据，作为延伸加到了主版本号.次版本号.修订号后面，格式为X.Y.Z[-先行版本号][+版本编译元数据]

当要发布的大版本或者核心的Feature时，但是又不能保证这个版本的功能100%正确，这个时候就需要通过发布先行版本。

比较常见的先行版本包括：内测版本、灰度版本和RC版本。Semver规范中使用alpha、beta、rc来修饰即将要发布的版本。他们的含义为：

• alpha：内部版本，此版本表示该包在此阶段主要是以实现软件功能为主，同城只在开发者内部交流，一般来说此版本的Bug较多，需要继续修改。
• beta:公测版本，该版本相对于alpha已经有很大的改进，消除了重要的错误，但是还是存在一些缺陷，这个版本也会一直加入新的功能。
• rc:即Release candiate，正式版本的候选版本，该版本已经相当成熟，不存在导致错误的BUG，与即将发现的正式版相差无几，不会再加入新的功能，主要着重于除错。

Semver中的符号

指定的版本号

1.0.2只能使用1.0.2版本

^版本号

主版本号相同，且不小于指定版本号与下一个大版本之间的的版本

• ^1.0.2版本可以使用大于等于1.0.2，小于2.0.0的版本
• ^1.0.2-beta.1可以使用大于等于1.0.2-beta.1,小于2.0.0的版本，也可以使用1.0.2-beta.2等先行版本，但不可以使用主次修订版本号不同的其他先行版本，如不可用1.0.3-beta.1
• ^0.0.1主版本号为0，可以使用大于等于0.0.1，小于0.0.2的版本

~版本号

主版本号和次版本号都相同，且不小于指定版本号的所有版本

• ~1.0.2可以使用大于等于1.0.2小于1.1.0的版本

> < = >= <=版本号

指定版本号的范围

• >=3.0.0，可以使用3.0.0以上的版本

-版本号

两边必须有空格

• 1.0.1 - 2.0.2可以使用大于等于1.0.1，小于等于2.1.2的所有版本

空格版本号 || 版本号

空格表示AND,||表示OR

• 1.2.7 || >= 1.2.9 < 2.0.0可以使用1.2.7或者大于等于1.2.9小于等于2.0.0的版本

*版本号

所有的版本都可用

X版本号

• 1.x可以使用主版本号为1的版本
• 1.1.x可以使用主版本号为1，次版本号为1的版本