语义化版本控制规范
一、问题
如果没有一个统一完善的语义化版本规范， 开发者安装某个软件包时，发现这个软件包里又依赖不同特定版本的其它软件包。随着系统功能越来越复杂，依赖的软件包越来越多，依赖关系也越来越深，这个时候可能面临版本控制被锁死的风险，也就是出现“依赖地狱” 问题。
二、说明
语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 建立。
官网地址：semver.org/
规范的概要如下：
版本格式：主版本号.次版本号.修订号
- 主版本号： 功能性主导的规划实现，非兼容性修改。
- 次版本号： 向下兼容的功能性的新增与修改。
- 修订号：向下兼容的问题修正。
- 修订号：修复问题时使用，采用递增方式。
三、语义化版本控制规范
- 标准的版本号必须采用XYZ的格式，并且X、Y 和 Z 为非负的整数，禁止在数字前方补零，版本发布需要严格递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
- 某个版本正式发行后，禁止改变该版本的内容，任何修改都必须基于发布的新版本。
- 主版本号为零（0.y.z）的软件， 标识处于研发初始阶段，一切都可能随时发生变化或被改变。这样的版本提供的公共 API 不应该被视为稳定版。
- 1.0.0 的版本号用于界定正式版本的形成。当软件发布到了正式环境，或者有稳定的API功能时，就可以发布1.0.0版本。
- 次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增。也可以在内部程序有大量新功能或改进被加入时递增。每当次版本号递增时，修订号必须归零。
- 修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改，比如线上的功能缺陷等。
- 主版本号 X（X.y.z | X > 0）必须在有非兼容性的修改时递增，比如出现新的功能需求。每当主版本号递增时，次版本号和修订号必须归零。
- 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。
- 先行的版本号可以被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止留白。先行版的优先级低于相关联的标准版本。 被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。例如：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92
- 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。由左到右依序比较每个标识符，第一个差异值用来决定优先层级，主版本号、次版本号和修订号以数值进行比较，例如：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。
四、实际案例说明
我们来看看目前最流行的前端框架之一的React最近5个月的版本发布日志：
从上图可以得出结论：
1.软件的版本通常由三位组成，形如：X.Y.Z
2.版本是严格递增的，此处是：16.2.0 -> 16.3.0 -> 16.3.1
3.在发布重要版本时，可以发布alpha, rc等先行版本
4.alpha和rc等修饰版本的关键字后面可以带上次数和meta信息
React 发布版本时做的相当到位，版本给人的感觉非常清晰，也很严谨。这得益于 Semver(语义化版本) 规范的功劳。
下面是遵从了Semver规范的React依赖图：
遵从了Semver规范的包依赖非常清晰，没有出现循环依赖、依赖冲突等常见问题
随时随地看视频
