We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
因为最近在做 Node 相关的项目,涉及到版本号的处理,根据版本号大小做升级 js 处理的,而因为多加了一位数,导致线上的 js 不能升级。
所以只能重写一个支持任意位数的版本号对比方法。
顺便先来一个语义化版本号的扫盲吧。
在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中。
在依赖高的系统中发布新版本套件可能很快会成为恶梦。
如果依赖关系过高,可能面临版本控制被锁死的风险(必须对每一个相依套件改版才能完成某次升级)。
而如果依赖关系过于松散,又将无法避免版本的混乱(假设兼容于未来的多个版本已超出了合理数量)。
当你专案的进展因为版本相依被锁死或版本混乱变得不够简便和可靠,就意味着你正处于依赖地狱之中。
作为这个问题的解决方案之一,就是用一组简单的规则及条件来约束版本号的配置和增长,也就是 语义化版本号。
语义化版本号
一般语义化版本号通常定义是这样的:
js 代码:
Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 主版本号 .子版本号 [.修正版本号 [.编译版本号 ]]
定界符一般使用 .
.
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
主版本号.次版本号.修订号
先行版本号及版本编译信息可以加到 “主版本号.次版本号.修订号” 的后面,作为延伸。
而且版本号都是递增的,在相同的位上递增、或者更高位递增,比如:'1.2.5.1' => '1.2.5.2'、'1.2.5.1' => '1.2.6.1'、'1.9.9.9' => '2.0.0.0'。
更详细的版本解释请看这里 语义化版本 2.0.0。
这样我们可以做版本号比较,这里提供一个我们项目中使用的方法,支持任意版本号位数的比较哦,比如 3 位的、4 位的。
// 3 位 Major_Version_Number.Minor_Version_Number[.Revision_Number] 主版本号 .子版本号 [.修正版本号] // 4 位 Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 主版本号 .子版本号 [.修正版本号 [.编译版本号 ]]
之所以支持任意版本号位数的比较,是因为版本号都是递增的,而以下的方法是从左到右,一位一位的比较的。
/** * 版本比较 VersionCompare * @param {String} curVersion 当前版本 * @param {String} supportVersion 比较版本 * @return {Boolean} false 当前版本小于比较版本返回 true */ const versionCompare = (curVersion, supportVersion) => { if (!curVersion) { return false; } if (!supportVersion) { return false; } // 相等 也是比较关键的一步 if (curVersion === supportVersion) { return true; } const curArr = curVersion.split('.'); const supportArr = supportVersion.split('.'); for (let i = 0; i < curArr.length; i += 1) { // 只有当两个版本号不相等才比较 if (+curArr[i] !== +supportArr[i]) { // 直接返回 结果,中止循环 return +curArr[i] > +supportArr[i]; } } return false; };
使用也很简单:
// 3 位比较 versionCompare('1.3.3', '1.2.5'); // true versionCompare('1.1.3', '1.2.5'); // false versionCompare('1.2.5', '1.2.5'); // true // 4 位比较 versionCompare('1.2.5.1', '1.2.5.1'); // true versionCompare('1.2.3.4', '1.2.3.5'); // false versionCompare('1.2.3.6', '1.2.3.5'); // true versionCompare('1.3.3.4', '1.2.3.5'); // true // 单 位上大于 10 的位进行比较 versionCompare('1.2.15.1', '1.2.5.1'); // true versionCompare('1.2.15.1', '1.2.16.1'); // false
这里需要注意的是根据我自己的业务逻辑 当前版本小于比较版本返回 false,当前版本等于比较版本返回 true。
你可以根据自己的业务逻辑修改代码。
有一段时间没写技术文章了啊 😂 实在惭愧。
下一篇原创应该是自己的年终总结了,今年的年终要比往年来得更晚一些,往年的年终总结都是 12 月下询就写好了的。
没办法,今年的 12 月份的确很忙,还没排上期,2020 的年终总结,会有 2021 年 1 月写好 😂 。
The text was updated successfully, but these errors were encountered:
biaochenxuying
No branches or pull requests
因为最近在做 Node 相关的项目,涉及到版本号的处理,根据版本号大小做升级 js 处理的,而因为多加了一位数,导致线上的 js 不能升级。
所以只能重写一个支持任意位数的版本号对比方法。
顺便先来一个语义化版本号的扫盲吧。
为什么需要语义化版本号?
在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中。
在依赖高的系统中发布新版本套件可能很快会成为恶梦。
如果依赖关系过高,可能面临版本控制被锁死的风险(必须对每一个相依套件改版才能完成某次升级)。
而如果依赖关系过于松散,又将无法避免版本的混乱(假设兼容于未来的多个版本已超出了合理数量)。
当你专案的进展因为版本相依被锁死或版本混乱变得不够简便和可靠,就意味着你正处于依赖地狱之中。
作为这个问题的解决方案之一,就是用一组简单的规则及条件来约束版本号的配置和增长,也就是
语义化版本号
。语义化版本号
一般语义化版本号通常定义是这样的:
js 代码:
定界符一般使用
.
版本格式:
主版本号.次版本号.修订号
,版本号递增规则如下:先行版本号及版本编译信息可以加到 “
主版本号.次版本号.修订号
” 的后面,作为延伸。而且版本号都是递增的,在相同的位上递增、或者更高位递增,比如:'1.2.5.1' => '1.2.5.2'、'1.2.5.1' => '1.2.6.1'、'1.9.9.9' => '2.0.0.0'。
更详细的版本解释请看这里 语义化版本 2.0.0。
比较方法
这样我们可以做版本号比较,这里提供一个我们项目中使用的方法,支持任意版本号位数的比较哦,比如 3 位的、4 位的。
之所以支持任意版本号位数的比较,是因为版本号都是递增的,而以下的方法是从左到右,一位一位的比较的。
js 代码:
使用也很简单:
js 代码:
这里需要注意的是根据我自己的业务逻辑 当前版本小于比较版本返回 false,当前版本等于比较版本返回 true。
你可以根据自己的业务逻辑修改代码。
最后
有一段时间没写技术文章了啊 😂 实在惭愧。
下一篇原创应该是自己的年终总结了,今年的年终要比往年来得更晚一些,往年的年终总结都是 12 月下询就写好了的。
没办法,今年的 12 月份的确很忙,还没排上期,2020 的年终总结,会有 2021 年 1 月写好 😂 。
The text was updated successfully, but these errors were encountered: