语义化版本控制规范

语义化版本控制规范

1、问题

若是没有一个统一完善的语义化版本规范， 开发者安装某个软件包时，发现这个软件包里又依赖不一样特定版本的其它软件包。随着系统功能愈来愈复杂，依赖的软件包愈来愈多，依赖关系也愈来愈深，这个时候可能面临版本控制被锁死的风险，也就是出现“依赖地狱” 问题。

2、说明

语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 创建。
官网地址：https://semver.org/

规范的概要以下：
版本格式：主版本号.次版本号.修订号

1. 主版本号： 功能性主导的规划实现，非兼容性修改。
2. 次版本号： 向下兼容的功能性的新增与修改。
3. 修订号：向下兼容的问题修正。
4. 修订号：修复问题时使用，采用递增方式。

3、语义化版本控制规范

1. 标准的版本号必须采用XYZ的格式，而且X、Y 和 Z 为非负的整数，禁止在数字前方补零，版本发布须要严格递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
2. 某个版本正式发行后，禁止改变该版本的内容，任何修改都必须基于发布的新版本。
3. 主版本号为零（0.y.z）的软件， 标识处于研发初始阶段，一切均可能随时发生变化或被改变。这样的版本提供的公共 API 不该该被视为稳定版。
4. 1.0.0 的版本号用于界定正式版本的造成。当软件发布到了正式环境，或者有稳定的API功能时，就能够发布1.0.0版本。
5. 次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增。也能够在内部程序有大量新功能或改进被加入时递增。每当次版本号递增时，修订号必须归零。
6. 修订号 Z（x.y.Z | x > 0）必须在只作了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改，好比线上的功能缺陷等。
7. 主版本号 X（X.y.z | X > 0）必须在有非兼容性的修改时递增，好比出现新的功能需求。每当主版本号递增时，次版本号和修订号必须归零。
8. 版本的优先层级指的是不一样版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。
9. 先行的版本号能够被标注在修订版以后，先加上一个链接号再加上一连串以句点分隔的标识符来修饰。标识符必须由 ASCII 字母数字和链接号 [0-9A-Za-z-] 组成，且禁止留白。先行版的优先级低于相关联的标准版本。 被标上先行版本号则表示这个版本并不是稳定并且可能没法知足预期的兼容性需求。例如：1.0.0-alpha、1.0.0-alpha.一、1.0.0-0.3.七、1.0.0-x.7.z.92
10. 版本的优先层级指的是不一样版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。由左到右依序比较每一个标识符，第一个差别值用来决定优先层级，主版本号、次版本号和修订号以数值进行比较，例如：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。

4、实际案例说明

咱们来看看目前最流行的前端框架之一的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