共计 1798 个字符，预计需要花费 5 分钟才能阅读完成。
语义化版本控制标准
一、问题
如果没有一个对立欠缺的语义化版本标准，开发者装置某个软件包时，发现这个软件包里又依赖不同特定版本的其它软件包。随着零碎性能越来越简单，依赖的软件包越来越多，依赖关系也越来越深，这个时候可能面临版本控制被锁死的危险，也就是呈现“依赖天堂”问题。
二、阐明
语义化版本控制的标准是由 Gravatars 创办者兼 GitHub 独特创办者 Tom Preston-Werner 建设。
官网地址：https://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 标准的包依赖十分清晰，没有呈现循环依赖、依赖抵触等常见问题
本文由 mirson 创作分享，如需进一步交换，请加 QQ 群：19310171 或拜访 www.softart.cn