semver库不完全指南

semver 库用于进行语义化的版别断定

semver 调用了 lru-cache 库

.clean(version)

将传入的版别号尽量收拾（收拾）为一个契合语义化版别规范的版别号

1. 若传入的版别号有效会回来正确的版别号，若无效，会回来null
2. 关于传入的是一个区间（规模）内的版别时无法识别

     semver.clean(' = v 2.1.5foo') // null
     semver.clean(' = v 2.1.5foo', { loose: true }) // '2.1.5-foo' （运用 loose 时断定会宽松一些）
     semver.clean(' = v 2.1.5-foo') // null
     semver.clean(' = v 2.1.5-foo', { loose: true }) // '2.1.5-foo'
     semver.clean('=v2.1.5') // '2.1.5'
     semver.clean(' =v2.1.5') // 2.1.5
     semver.clean(' 2.1.5 ') // '2.1.5'
     semver.clean('~1.0.0') // null

.gt(v1, v2)

断定 v1 > v2 回来 boolean

.gte(v1, v2)

断定 v1 >= v2 回来 boolean

.lt(v1, v2)

断定 v1 < v2 回来 boolean

.lte(v1, v2)

断定 v1 <= v2 回来 boolean

.eq(v1, v2)

断定 v1 == v2 回来 boolean

在某些状况下即使不是彻底持平的字符串也或许回来 true 比方 semver.eq("v1.0.0", "1.0.0")) // true,semver.neq("version1.0.0", "1.0.0") 会报版别号无效的类型过错。semver 也做了一些退让。

neq(v1, v2)

断定 v1 != v2

semver.neq("v1.0.0", "1.0.0") // false

cmp(v1, comparator, v2)

传入一个比较字符串进行版别号比照

• == 与 === 不同，像"v1.0.0", "1.0.0" 运用 == 回来 true，=== 回来 false
• '' 与 == 与 = 相同

compare(v1, v2)

• v1 == v2 // return 0
• v1 > v2 // return 1
• v1 < v2 // return -1

rcompare(v1, v2)

与 compare 恰好相反

• v1 == v2 // return 0

• v1 > v2 // return -1

• v1 < v2 // return 1

diff(v1, v2)

semver.diff('v1.0.0-2.0.0', '1.0.0-2.0.0') // null
semver.diff('v1.0.0-3.0.0', '1.0.0-2.0.0') // prerelease
semver.diff('v2.0.0-2.0.0', '1.0.0-2.0.0') // premajor
semver.diff('v1.1.0-2.0.0', '1.0.0-2.0.0') // preminor
semver.diff('v1.0.1-2.0.0', '1.0.0-2.0.0') // prepatch
semver.diff('v2.0.0', '1.0.0') // major
semver.diff('v1.1.0', '1.0.0') // minor
semver.diff('v1.0.1', '1.0.0') // patch

• 首先用 compare 判等，若持平则回来 null ，第一个这种规模持平的状况也除掉出去了
• 规模内前面不等会回来 pre + 不等的部分称号，若持平但是后边不持平一概回来 prerelease

• Returns difference between two versions by the release type (major,premajor,minor,preminor,patch,prepatch, orprerelease), or null if the versions are the same.

什么是语义化版别

语义化版别的呈现是为了解决所谓的“dependency hell.”，即随着项目越来越大，功能项越来越多，每一次大的改版会包括许多小功能点的更新，而没有清晰、语义化的版别界说、清晰的文档说明，会让代码维护越来越杂乱，到最后成为所谓的“dependency hell.”，因而语义化的版别操控就此应运而生，一般也需求配合具体的版别更新文档，讲明版别更新时添加（削减、批改）了哪些功能点，或许修复了哪些bug。

比方之前在steam上玩一些小公司写的游戏的时分，有时分版别更新只会补白上批改了已知的过错等相似状况，这样会导致一个问题，打补丁的关键开发人员当时对这一补丁很清楚，知道哪里改了，乃至知道改了代码的多少到多少行等等，但是等半年后、一年后在进行项目复盘的时分就会发现，这样的补白简直是灾祸，这一点深有感触。

因而语义化版别操控的呈现不是单单一个数字化标识，而是需求各方面一起配合，需求具体的文档描绘，乃至需求专人来进行文档维护，这在大型项目中是必不可少的，而现在许多小型公司本着能省则省的准则，将这块看似无关紧要的内容省略了来节约本钱，反而给项目发展埋下了隐患，导致后期需求支付成倍的人力、物力、财力来添补这个坑，你的领导看到你们在忙，年与时驰意与日去，到最后也只知道你们在忙，项目进展却会越来越慢，矛盾就会繁殖，或许这也属于所谓“内耗”的一部分吧。

版别格局含义如下：主版别号.次版别号.修订号，版别号递加规矩如下：

1. 主版别号：做了不兼容的 API 批改，
2. 次版别号：做了向下兼容的功能性新增，
3. 修订号：做了向下兼容的问题批改。

先行版别号及版别编译信息能够加到“主版别号.次版别号.修订号”的后边，作为延伸。

更为具体的版别界说规范在这里 语义化版别，下面摘抄几个个人认为比较重要的点：

1. 运用语义化版别操控的软件必须（MUST）界说公共 API。该 API 能够在代码中被界说或呈现于谨慎的文档内。不管何种形式都应该力求精确且完好。
2. 标记版别号的软件发行后，制止（MUST NOT）改动该版别软件的内容。任何批改都必须（MUST）以新版别发行。
3. 主版别号为零（0.y.z）的软件处于开发初始阶段，一切都或许随时被改动。这样的公共 API 不该该被视为稳定版。
4. 先行版别号能够（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且制止（MUST NOT）留白。数字型的标识符制止（MUST NOT）在前方补零。先行版的优先级低于相关联的规范版别。被标上先行版别号则表明这个版别并非稳定而且或许无法满意预期的兼容性需求。典范：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
5. 版别的优先层级指的是不同版别在排序时怎么比较。

• 判别优先层级时，必须（MUST）把版别依序拆分为主版别号、次版别号、修订号及先行版别号后进行比较（版别编译信息不在这份比较的列表中）。

• 由左到右依序比较每个标识符，第一个差异值用来决议优先层级：主版别号、次版别号及修订号以数值比较。

  例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。

• 当主版别号、次版别号及修订号都相同时，改以优先层级比较低的先行版别号决议。

  例如：1.0.0-alpha < 1.0.0。

• 有相同主版别号、次版别号及修订号的两个先行版别号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决议：

  a. 只有数字的标识符以数值高低比较。

  b. 有字母或连接号时则逐字以 ASCII 的排序来比较。

  c. 数字的标识符比非数字的标识符优先层级低。

  d. 若最初的标识符都相同时，栏位比较多的先行版别号优先层级比较高。

  例如：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。

像“v1.2.3”这样的写法其实并不是一个正规的语义化的版别号。但是，在语义化版别号之前添加前缀 “v” 是用来表明版别号的常用做法。在版别操控系统中，将 “version” 缩写为 “v” 是很常见的。比方：git tag v1.2.3 -m "Release version 1.2.3"中，“v1.2.3” 表明标签称号，而 “1.2.3” 是语义化版别号。