一.格式
版本号为MAJOR.MINOR.PATCH，点号是分隔符：
MAJOR。进行了不兼容的API改动
MINOR。添加了向后兼容的新特性
PATCH。进行了向后兼容的bug修复
所以，一般不更新依赖package的主版本（MAJOR）
二.范围
用于依赖管理，声明目标package版本范围，为自动更新依赖提供支持
* | x | X
接受任何可用版本，默认取最新的。不要用，主版本更新可能会引发bug
MAJOR | MAJOR.MINOR
分别表示
<m+1和<m.n+1，用\*或者x（m.x.x | m.n.*）也可以表达相同的范围-，<，<=，>和>=
m.n.p - M.N.P表示>=m.n.p且<=M.N.P~
~m.n.p表示>=m.n.p且<m.n+1.0^
^m.n.p表示>=m.n.p且<m+1.0.00.n.p
主版本号为0表示处于初步开发阶段，所有东西随时都可能变动，MINOR和PATCH都没有意义。此时^前缀无效，
^0.n.p等价于0.n.p。~前缀仍然有效
三.注意事项
语义化版本控制只用于开发环境。也就是说，如果担心语义化版本控制会把bug引入生产环境，就说明用错了。
只在开发环境中使用的具体方法如下：
用package.json的”bundledDependencies”打包依赖
用
npm shrinkwrap指令创建特定时刻的依赖层级结构快照把依赖随应用一起加入版本控制（比如git）
四.关于测试版
Alpha、Beta、Gamma与α、β、λ谐音，是希腊字母前三个字母，用来表示软件开发过程中测试的三个阶段：
Alpha
内测版，内部交流或者专业测试人员测试用
Beta
公测版，专业爱好者大规模测试用，存在一些缺陷，该版本也不适合一般用户安装
Gamma
比较成熟的测试版，与即将发行的正式版相差无几
RC
是Release Candidate的缩写，意思是发布倒计时，候选版本，处于Gamma阶段，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。从Alpha到Beta再到Gamma是改进的先后关系，但RC1、RC2往往是取舍关系
Stable
稳定版。在开源软件中，都有stable版，这个就是开源软件的稳定发行版（对Node来说不是这样的，详细请查看Windows/Linux下Node更新）
对于范围>1.2.3-alpha.3，版本1.2.3-alpha.7符合条件，而3.4.5-alpha.9却不满足条件。虽然3.4.5-alpha.9实际上大于1.2.3-alpha.3，但是根据SemVer的排序规则，这个版本范围只是接受1.2.3的测试版，而不接受其他版本的测试版。当然3.4.5满足条件，因为它不是测试版，并且大于1.2.3-alpha.7
这么做是有两个目的，首先测试版会经常更新并且可能包含不适合公开的重大改动，因此被排除在范围之外。再者，虽然用户明确此次使用有风险的测试版本，然而下一版本的测试版被包含进来仍然是不合适的
五.总结
不要用固定版本号的依赖，因为补丁（PATCH）更新可能会修复现有bug，一般有三种：
谨慎控制依赖版本：使用
^前缀，表示只更新补丁版本，不跟主版本和小版本。适用于更新不频繁的趋于稳定的项目（比如should）稍微宽松一点：使用
~前缀，表示不跟主版本，只更新小版本和补丁。适用于长期频繁更新的大项目（比如express）最宽松的：使用
*前缀，取最新版本。适用于个人小项目，实验性的项目（比如myproj）
