今天早读课推送文章主要介绍语义化版本控制规范，也即我们常说的版本（号）的管理规范。 此外，其实工作中还有很多其他各种各样“号”管理，如分支号，迭代号等也可借鉴。

关键词：依赖地狱、语义化版本控制规范（SemVer）、版本号

摘要

• 版本格式：主版本号.次版本号.修订号
• 版本号递增规则如下：
  1. 主版本号：当你做了不兼容的API修改
  2. 次版本号：当你做了向下兼容的功能性新增
  3. 修订号：当你做了向下兼容的问题修正
  4. 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

什么是“依赖地狱”

文中介绍了一个软件管理领域的“依赖地狱”的概念，即Dependency Hell。在一个高依赖的系统中发布新版本时，可能需要对所依赖的每一个“套件”才能完成升级，这样版本被锁死。但是如果你的依赖关系不这么紧密的话（松散，即依赖哪个版本都行），那么版本就很容易混乱。这样，无论是版本锁死或版本混乱，即为“依赖地狱”。

解决方案

解决上述问题的方法，即用一组简单的规则及条件来约束版本号的配置和增长（但又需要保证一定的灵活性）。即语义化版本控制规范（Semantic Versioning Specification，SemVer）。有如下描述关键词（REC 2119）：MUST（必须）、MUST NOT（禁止）、REQUIRED、SHALL、SHALL NOT、SHOULD（可）、SHOULD NOT、RECOMMENDED、MAY（可以）、OPTIONAL。

简单摘取一些，详细规范可**{阅读原文}**：

• 标准的版本号“必须 MUST”采用XYZ的格式，其中X、Y和Z为非负的整数，且“禁止 MUST NOT”在数字前方补零。X是主版本号，Y是次版本号、Z是修订号。每个元素“必须 MUST”以数值来递增。
• 标记版本号的软件发行后，“禁止 MUST NOT”改变该版本软件的内容，任何修改都“必须 MUST”以新版本发行。
• 主版本号为0（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变，这样的公共API不应该被视为稳定版。
• 1.0.0的版本号用于界定公共API的形成。这一版本之后所有的版本号更新都基于公共API及其修改内容。
• 每当次版本号递增时，修订号“必须 MUST ”归零。每当主版本号递增时，次版本号和修订号“必须 MUST ”归零。
• 先行版本号“可以 MAY”被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。
  • 标识符号“必须 MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组成，且“禁止 MUST NOT”留白。数字型的标识符号“禁止 MUST NOT”在前方补零。
  • 先行版的优先级低于相关联的标准版本，被标上先行版本号则标识这个版本并非稳定而且可能无法达到兼容的需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-3.7、1.0.0-x.7.z.92等
• 版本编译信息“可以 MAY”被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符号来修饰，语法规则同先行版本号
  • 标识符号“必须 MUST”由ASCII码的英数字和连接号[0-9A-Za-z-]组成，且“禁止 MUST NOT”留白。
  • 当判断版本的优先层级时，编译版本信息“可 SHOULD”被忽略，因此当只有版本编译信息有差异时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85

其他

在CS中，类似的规范还有很多，可能与技术水平无关，但是和技术素养有关，能让你的系统或代码更容易被理解。

（本篇完）