版本命名及限定规则详解

理解版本命名及限定规则

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


版本命名规则

咱们常见的版本命名格式为前端

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

语义化版本命名规则

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

序号 格式要求 说明
x 非负整数 主版本号(major),进行不向下兼容的修改时,递增主版本号
y 非负整数 次版本号(minor),保持向下兼容,新增特性时,递增次版本号
z 非负整数 修订号(patch),保持向下兼容,修复问题但不影响特性时,递增修订号
  • 0.y.z 表示开发阶段,一切可能随时改变,非稳定版。
  • 1.0.0 界定此版本为初始稳定版,后面的一切更新都基于此版本进行修改。

版本状态

描述方式 说明 含义
αa alpha 版 内测版本,内部测试的版本,bug 较多
βb beta 版 公测版本,给外部进行测试的版本,有缺陷
γg Gamma 版 至关成熟的测试版,于发行版相差无几
rc Release Candidate 是前面三种测试版的进一步版本,实现了所有功能,清除了大部分 bug,接近发布倒计时,有时会进一步细分为 rc1,rc2

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

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

描述方式 说明 含义
Demo 演示版 只集成了正式版部分功能,没法升级
SP SP1 是 service pack 的意思表示升级包
Trial 试用版 试用版
Unregistered 未注册 有功能或时间限制的版本
Lite 精简版 只含有正式版核心功能
enhance 加强版 属于正式版1
free 免费版 自由使用版本
release 发行版 有时间限制
upgrade 升级版 有功能加强或修复 bug
Retail  零售版 单独发售
Cardware 共享版 公用许可证

版本限定

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

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

表示安装 0.13.22 版本的 karma.测试

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

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

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

    严格来说对 ~,^ 的表述须要结合具体的包管理工具和版本号规则来肯定.可是对于通常使用记住以下原则.
    ^ 是确保版本兼容性时,默认对次版本号的限定约束
    ~ 是确保版本兼容性时,默认对补丁号的约束htm

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

  • 版本描述

    • * 通配符,相似 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

相关文章
相关标签/搜索