版本命名及限定规则详解

Zhuxy 发布于2019-06-28 13:51 / 489人阅读

理解版本命名及限定规则

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

版本命名规则

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

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

name为可选字段,一般为 v,表示 version

x.y.z 为各版本的序号，遵循语义化版本命名规范
实际上基于此规范,不应该在版本前出现 name 字段.

state 可选字段,表示版本状态,例如 b 表示 beta 测试版,其他常见状态,后有详述

语义化版本命名规则

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

序号	格式要求	说明
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

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

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

描述方式	说明	含义
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.

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

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

< 小于某一版本号

<= 小于等于某一版本号

> 大于某一版本号

>= 大于等于某一版本号

= 等于某一版本号,没有意义和直接写该版本号一样

~ 基于版本号描述的最新补丁版本

^ 基于版本号描述的最新兼容版本

- 某个范围,他应该出现在两个版本描述中间,实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一

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

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

版本描述

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

云服务器 GPU云服务器变量命名规则公司域名的命名规则二级域名命名规则服务器的命名规则

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/25912.html

正则表达式详解

摘要：学习正则表达式也是如此，循序渐进，方能厚积薄发。概念分组捕获是指将想要匹配的正则表达式用小括号括起来，然后与限定符组合使用，可以连续匹配符合规则的字符串。正则表达式是一个非常有用的用来匹配验证字符串的工具。很多人觉得正则表达式规则繁多，学了也会忘记，不如等到需要使用的时候再去查阅即可。这样的观点也无可厚非，不过我曾经看到过一个绝妙的关于阅读的比喻，阅读就像是将竹篓浸入到水里面，虽然捞...

keelii 2019-08-23 13:51 评论0 收藏0
【转】php命名空间

摘要：命名空间可以解决以下两类问题用户编写的代码与内部的类函数常量或第三方类函数常量之间的名字冲突。在命名空间内部访问全局类函数和常量调用全局函数访问全局常量实例化全局类命名空间和动态语言特征命名空间的实现受到其语言自身的动态特征的影响。 PHP 命名空间(namespace)是在PHP 5.3中加入的，如果你学过C#和Java，那命名空间就不算什么新事物。不过在PHP当中还是有着相当重要...

Jrain 2019-06-27 16:28 评论0 收藏0
Spring详解3.Bean的装配

摘要：的依赖关系，根据依赖关系配置完成之间的装配。的行为信息，如生命周期范围及生命周期各过程的回调函数。使用该种装配模式时，优先匹配参数最多的构造函数。如果提供了默认的构造函数，则采用否则采用进行自动装配。点击进入我的博客 1 Spring容器与Bean配置信息 Bean配置信息 Bean配置信息是Bean的元数据信息，它由一下4个方面组成： Bean的实现类 Bean的属性信息，如数...

endiat 2019-08-16 14:15 评论0 收藏0
Web前端开发规范文档

摘要：前端开发规范文档规范目的使开发流程更加规范化。中的非注释类中文字符须转换成编码使用，以避免编码错误时乱码显示。文件规范文件名用英文单词，多个单词用驼峰命名法。书写规范命名规范。图片规范命名应用小写英文数字组合，便于团队其他成员理解。 Web前端开发规范文档规范目的：使开发流程更加规范化。通用规范： TAB键用两个空格代替（WINDOWS下TAB键占四个空格，LINUX下TAB键...

付伦 2019-08-28 18:16 评论0 收藏0
Web前端开发规范文档

摘要：前端开发规范文档规范目的使开发流程更加规范化。中的非注释类中文字符须转换成编码使用，以避免编码错误时乱码显示。文件规范文件名用英文单词，多个单词用驼峰命名法。书写规范命名规范。图片规范命名应用小写英文数字组合，便于团队其他成员理解。 Web前端开发规范文档规范目的：使开发流程更加规范化。通用规范： TAB键用两个空格代替（WINDOWS下TAB键占四个空格，LINUX下TAB键...

Chiclaim 2019-08-21 10:39 评论0 收藏0