理解版本命名及限定规则

前言:讲解版本命名和版本限定的相关知识

版本命名规则

我们常见的版本命名格式为

[name].x.y.z-[state]

• name为可选字段,一般为 v,表示 version
• x.y.z 为各版本的序号，遵循 语义化版本命名规范
  实际上基于此规范,不应该在版本前出现 name 字段.
• state 可选字段,表示版本状态,例如 b 表示 beta 测试版,其他常见状态,后有详述

语义化版本命名规则

该规则对版本的迭代命名,做了很好的限制.
核心规则如下.

• 0.y.z 表示开发阶段，一切可能随时改变，非稳定版。
• 1.0.0 界定此版本为初始稳定版，后面的一切更新都基于此版本进行修改。

版本状态

实际上大部分前端工具均遵守上述规则

在商业软件中还会见到如下字段.

版本限定

在进行包管理时,为了保证安装依赖的兼容性.
必须对依赖包版本进行限定.参考 npm 限定描述
举例如下

{
  "devDependencies": {
    "karma": "0.13.22"
  }
}

表示安装 0.13.22 版本的 karma.

为了方便理解,版本限定的语法简述为为 [范围描述]<版本号描述>

• 范围描述可选,必须配和版本描述确定范围,无法独立存在

  • < 小于某一版本号
  • <= 小于等于某一版本号
  • > 大于某一版本号
  • >= 大于等于某一版本号
  • = 等于某一版本号,没有意义和直接写该版本号一样
  • ~ 基于版本号描述的最新补丁版本
  • ^ 基于版本号描述的最新兼容版本
  • - 某个范围,他应该出现在两个版本描述中间,实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一

  严格来讲对 ~,^ 的表述需要结合具体的包管理工具和版本号规则来确定.但是对于一般使用记住如下原则.
  ^ 是确保版本兼容性时,默认对次版本号的限定约束
  ~ 是确保版本兼容性时,默认对补丁号的约束

  利用 ^,~ 的意义在于确保工具包对依赖版本的兼容性,排除主版本更迭,
  造成依赖失效的可能.

• 版本描述

  • * 通配符,类似 glob 模式 *
  • x,X 约等于 * 号,通常用于次版本和补丁的通配.

  0.x 警惕这种版本,说明该依赖还未稳定(如果它遵守语义化命名的话),此外由于 0.x 版本随时可能改变,此时 ^,~ 的都表示为对补丁版的限制.

相关举例如下

< 1.2.3     小于1.2.3 的版本均可 
= 1.2.3     只支持等于1.2.3 的版本 
<= 1.2.3    只支持小于等于1.2.3 的版本
> 1.2.3     只支持大于 1.2.3 的版本
>= 1.2.3    只支持大于等于 1.2.3 的版本
1.2.3-2     支持 >=1.2.3 <3.0.0 的版本
1.x.1       支持 >=1.0.1 <1.1.0 的版本
*           支持 >= 0.0.0 的版本
""          同 *
1           表示 >=1.0.0 <2.0.0 其余任意位置为空相似
1.0         >= 1.0.0 < 1.1.0
~1.1.1      >=1.1.1 <1.2.0
~1.1        >=1.1.0 <1.2.0
~1          >=1.0.0 <2.0.0
^1.1.1      >=1.1.1 <2.0.0
^0.1.1      >=0.1.1 <0.2.0 注意这里,不要以为是 0.1.1-1.0.0 之间
^0.0.1      >=0.0.1 <0.0.2 同上,请注意

注意大部分包管理工具均遵守上述规则,但是在进行版本限定时,请参考包管理工具的配置项说明,确定语法格式.

总结

最常用的知识

核心命名规则

• 版本号通常称为 x.y.z

  • x 主版本号,一般向下不兼容时增加此值
  • y 次版本号,向下兼容,添加新特性时增加此值
  • z 补丁号,修复问题为改变特性时增加此值
  • a,b,rc 分别表示 内测,公测,发行状态

版本限定

• ~ 在依赖版本兼容下,最近的补丁版
• ^ 在依赖版本兼容下,最近的次版本

重点是保证版本依赖的兼容性,不允许出现依赖的主版本号范围可变,即使你的开发包依旧可用

参考资料

语义化版本规范

npm 版本说明

composer version constraints

百度文库-版本说明详解

wiki 软件版本

What’s the difference between tilde(~) and caret(^) in package.json