语义话版本号

为什么需要语义化版本号？

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的套件越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。

在依赖高的系统中发布新版本套件可能很快会成为恶梦。

如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个相依套件改版才能完成某次升级）。

而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。

当你专案的进展因为版本相依被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。

作为这个问题的解决方案之一，就是用一组简单的规则及条件来约束版本号的配置和增长，也就是语义化版本号。

语义化版本号

一般语义化版本号通常定义是这样的：

Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]

主版本号            .子版本号              [.修正版本号       [.编译版本号  ]]

定界符一般使用 .

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

• 主版本号(major)：当你做了不兼容的 API 修改
• 次版本号(minor)：当你做了向下兼容的功能性新增，可以理解为 Feature 版本
• 修订号(patch)：当你做了向下兼容的问题修正，可以理解为 Bug fix 版本
  先行版本号及版本编译信息可以加到 “主版本号.次版本号.修订号” 的后面，作为延伸。

而且版本号都是递增的，在相同的位上递增、或者更高位递增，比如：’1.2.5.1’ => ‘1.2.5.2’、’1.2.5.1’ => ‘1.2.6.1’、’1.9.9.9’ => ‘2.0.0.0’。