04. 语义化版本

语义化版本

作为解决依赖问题的方案，我们必须用一组简单的规则来约束版本号的管理。这些规则包含但不仅限于各种开源、闭源软件中的一些惯例。

一旦定义了公共的 API，就可以透过修改相应的版本号来向大家说明修改类型。考虑使用这样的版本号格式：X.Y.Z （主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订版本号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

引用自 http://semver.org/lang/zh-CN/

如果大家都遵守这种约定，那么我们在做依赖库的版本升级时，将不会再像以前一样痛苦。

Tom Preston-Werner 还列举了11条语义化版本的规范，这里就不一一列举了，感兴趣的朋友参考这里：http://semver.org/。满足了这些规范，每次版本号的变动，都能告诉依赖这个库的人，你在新的版本中做了什么样的改动，他可以很快决定是否要升级。

NPM

下面我们以 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