package.json中版本号详解 来源
https://blog.csdn.net/weixin_40817115/article/details/86611179
指定版本：比如1.2.2，遵循“大版本.次要版本.小版本”的格式规定，安装时只安装指定版本。
波浪号（tilde）+指定版本：比如~1.2.2，表示安装1.2.x的最新版本（不低于1.2.2），但是不安装1.3.x，也就是说安装时不改变大版本号和次要版本号。
^号（caret）+指定版本：比如ˆ1.2.2，表示安装1.x.x的最新版本（不低于1.2.2），但是不安装2.x.x，也就是说安装时不改变大版本号。需要注意的是，如果大版本号为0，则号的行为与波浪号相同，这是因为此时处于开发阶段，即使是次要版本号变动，也可能带来程序的不兼容。
~ 会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
^ 会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0
这意味着安装最新版本的依赖包
推荐使用~，只会修复版本的bug，比较稳定
使用^ ，有的小版本更新后会引入新的问题导致项目不稳定，
比如：之前的weex老项目安装依赖后页面无法显示，修改依赖版本后才正常
那么~和^的作用和区别是什么呢？
会匹配最近的小版本依赖包，比如1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
会匹配最新的大版本依赖包，比如1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0
详细可参考http://stackoverflow.com/questions/22343224/whats-the-difference-between-tilde-and-caret-in-package-json
那么该如何选择呢？当然你可以指定特定的版本号，直接写1.2.3，前面什么前缀都没有，这样固然没问题，但是如果依赖包发布新版本修复了一些小bug，那么需要手动修改package.json文件；~和^则可以解决这个问题。
但是需要注意版本更新可能比较大，会造成项目代码错误，比如这篇文章（http://blog.csdn.net/u014291497/article/details/54427103）的问题就是因为package.json使用1.5.7造成的，1.6版本的包与现有代码不兼容。
所以建议使用~来标记版本号，这样可以保证项目不会出现大的问题，也能保证包中的小bug可以得到修复。
或者版本号写*，这意味着安装最新版本的依赖包，但缺点同上，可能会造成版本不兼容，慎用！
参考链接：https://scotch.io/tutorials/node-and-npm-version-numbering-guide-and-best-practices#-a-specific-version
一、版本号简介
软件版本号有四部分组成：
第一部分为主版本号，变化了表示有了一个不兼容上个版本的大更改。
第二部分为次版本号，变化了表示增加了新功能，并且可以向后兼容。
第三部分为修订版本号，变化了表示有bug修复，并且可以向后兼容。
第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release
eg：
关于希腊版本号：
Base
此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是 页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
Alpha
软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者 内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试 人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可 将软件版本标注为alpha版。
Beta
该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次 测试来进一步消除，此版本主要的修改对象是软件的UI。修改的的Bug 经测试人 员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。
RC
该版本已经相当成熟，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。
Release
该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。
二、 package.json中的依赖
dependencies字段指定了项目运行所依赖的模块，devDependencies指定项目开发所需要的模块(测试阶段和过渡阶段的依赖应该加在DevDependencies中)。它们都指向一个对象。该对象的各个成员，分别由模块名和对应的版本要求组成，表示依赖的模块及其版本范围。
eg:
{
"name": "ethopia-waza",
"description": "a delightfully fruity coffee varietal",
"version": "1.2.3",
"devDependencies": {
"coffee-script": "~1.6.3"
},
"dependencies": {
"bar": "file:../foo/bar"
}
}
模块名和版本号被假定组合成一个唯一的标识符。
version字段必须能够被node-semver解析。node-semver作为依赖项被捆绑进了npm中。
其实，版本号的写法并不是只有我们熟知的 波浪号( ~3.8.0 )、插入号( ^3.8.0 )和3.8.0，只要是能够被node-semver解析的写法都是可以的。
主要有以下几种：
示例：
version 必须确切匹配这个version
version 必须大于这个version
=version 必须大于等于这个version
< version 必须小于这个version
<=version 必须小于等于这个version
~version 大约相当于version
^version 与version兼容
1.2.x 可以是1.2.0、1.2.1等，但不能是1.3.0
http://… URL作为依赖项
匹配任何版本
“”(空字符串) 匹配任何版本，和*一样
version1 - version2 相当于 >=version1 <=version2
range1 || range2 range1或range2其中一个满足时采用该version
git… Git URL作为依赖项
user/repo GitHub URLs
tag 一个以tag发布的指定版本，参考npm-tag
path/path/path 本地Paths
{
"dependencies": {
"foo": "1.0.0 - 2.9999.9999",
"bar": ">=1.0.2 <2.1.2", 必须大于等于1.0.2版本且小于2.1.2版本
"baz": ">1.0.2 <=2.3.4", 必须大于1.0.2版本且小于等于2.3.4版本
"boo": "2.3.1", 必须匹配这个版本
"boo": "~2.3.1", 约等于2.3.1，只更新最小版本，相当于2.3.X，即>=2.3.1 <2.4.0
"thr": "2.3.x",
"boo": "^2.3.1", 与2.3.1版本兼容，相当于2.X.X, 即>=2.3.1 < 3.0.0,不改变大版本号。
"qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
"asd": "http://asdf.com/asdf.tar.gz", 在版本上指定一个压缩包的url，当执行npm install 时这个压缩包会被下载并安装到本地。
"til": "~1.2",
"elf": "~1.2.3",
"two": "2.x",
"lat": "latest", 安装最新版本
"dyl": "file:../dyl", 使用本地路径
"adf": "git://github.com/user/project.git#commit-ish" 使用git URL加commit-ish
}
}
三、版本范围详解
连字符范围：X.Y.Z-A.B.C
指明版本范围
1.2.3 - 2.3.4： >=1.2.3 <=2.3.4
起始版本不全: 缺少的部分补0
1.2 - 2.3.4: 相当于1.2.0 - 2.3.4；
结束版本不全：所有以其开头的版本均符合要求
1.2.3 - 2.3 ：相当于 >=1.2.3 < 2.4.0
1.2.3 - 2: 相当于 >=1.2.3 < 3.0.0
带有X的版本范围:“1.2.X ”、“1.X” 、“1.2.*”
任何带有X、x 和 *的版本号都是有谁存在就要匹配谁。
*：>=0.0.0
“”: >=0.0.0
1.x: >=1.0.0 <2.0.0
1.2.x: >=1.2.0 <1.3.0
1: >=1.0.0 <2.0.0
1.2: >=1.2.0 <1.3.0
波浪号范围 ~1.2.3 ~1.2 ~1
~1.2.3: >=1.2.3 <1.3.0, 只能更新
~1.2: >=1.2.0 <1.3.0（相当于~1.2.0，1.2.x）
~1：>=1.0.0 <2.0.0 （相当于1.X，所有的1.X.X）
~1.2.3-beta.2: >=1.2.3-beta.2 <1.3.0