作为解决依赖问题的方案，我们必须用一组简单的规则来约束版本号的管理。这些规则包含但不仅限于各种开源、闭源软件中的一些惯例。
一旦定义了公共的 API，就可以透过修改相应的版本号来向大家说明修改类型。考虑使用这样的版本号格式：X.Y.Z （主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订版本号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。
如果大家都遵守这种约定，那么我们在做依赖库的版本升级时，将不会再像以前一样痛苦。
Tom Preston-Werner 还列举了11条语义化版本的规范，这里就不一一列举了，感兴趣的朋友参考这里：http://semver.org/。满足了这些规范，每次版本号的变动，都能告诉依赖这个库的人，你在新的版本中做了什么样的改动，他可以很快决定是否要升级。
下面我们以 NPM（一个 JavaScript 的包管理器，但它的作用不仅限于管理依赖包） 的版本号管理为例（https://youtu.be/kK4Meix58R4），具体介绍一下在实际项目中是如何工作的。
首先，如果你决定分享一个你开发的库给别人用，版本号应该从 1.0.0 开始。因为0.x.x 的版本意味着该库还处于开发阶段，可能随时会有大的改动带来一些不稳定性。这样别人也会根据自己的实际情况决定要不要使用这个库。
更多的时候，我们会用到很多别人的库。NPM 通过 package.json 文件来声明依赖，比如：
{
"dependencies" :
{
"foo1" : "~1.0.0",
"foo2" : "1.0",
"foo3" : "1.0.x",
"foo4" : ">=1.0.0 <1.1.0",
"bar1" : "^1.0.0",
"bar2" : "1",
"bar3" : "1.x",
"bar4" : ">=1.0.0 <2.0.0",
"bazz" : ">=1.0.0",
"abcd" : "1.0.0"
}
}
假设你是从1.0.0版本开始依赖一个库，在没有 lock 文件的情况下：
- 如果想自动升级修订版本，在 NPM 的世界里写成
foo1，foo2，foo3，foo4那样都行； - 如果想自动升级次版本，在 NPM 的世界里写成
bar1，bar2，bar3，bar4那样都行； - 如果想自动升级主版本，在 NPM 的世界里写成
bazz那样都行； - 如果出于某种原因比较保守，就想固定在某一个版本上，在 NPM 的世界里写成
abcd那样就好。
不知道有没有细心的朋友注意到了某个问题？
sleep(10s); //此处假装思考10秒
这里先解释一下，*，x，X，""（空字符），均表示任意一个非负整数。
在回到上面👆的问题，如果没想到也没关系。因为答案就在语义化版本的11条规范里：
- 必须升级修订版本号（Patch version），如果只有向下兼容的 Bug 修复。
- 必须升级次版本号（Minor version），如果有增加了向下兼容的新特性，或者标明某个 API 将被弃用。升级次版本号时，可能也会包含一些增加的内部特性或者优化，也可能包含一些修订版本级别的改动。一旦升级了次版本号，修订版本号必须重置为0。
- 必须升级主版本号（Major version），如果做了向下不兼容的改动。与此同时，可能会包含一些次版本和修订版本级别的改动。一旦升级了主版本号，次版本号和修订版本号都必须重置为0。
从前面的例子中可以看出，表示一个版本区间的方式多种多样。如何准确地描述一个版本区间呢？都有哪些方式呢？且听下回分解。
参考资源
http://semver.org/
https://tools.ietf.org/html/rfc2119
https://tools.ietf.org/html/draft-leiba-rfc2119-update-00
https://docs.npmjs.com/misc/semver
https://docs.npmjs.com/getting-started/semantic-versioning
