[TOC] # 语义化版本 首先，我们来了解一个东西：语义化版本 版本格式：主版本号.次版本号.修订号，版本号递增规则如下： 主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。 语义化版本一般我们使用 3 个部分来表示一个版本，例如：1.4.23，1 为主版本号，4 为次版本号，23 为修订号或者补丁版本号。当然你肯定也见过 1.0.0-alpha1 这样在后面添加修饰符号来表示先行版本。 那在 composer 使用过程中我们通常会有这几种写法： ## 不限定版本 极不推荐这样玩哦 使用 * 号来表示版本的时候，composer 会根据你配置中的 minimum-stability 的值情况来决定安装最新的 dev 还是 stable 版本。 比如： ~~~ "require": { "overtrue/wechat": "*" } ~~~ 根据上面语义化版本的定义，这样写就相当于允许大版本的安装，那你的代码在 composer 更新依赖后可能就跑不起来了（如果第三方包作者做了大版本更新）。 ## 使用 dev- 前缀加分支名 我们在自己开发一个包的时候，经常会用 dev-master 或者 dev-develop 来指定版本，它表示使用该分支下最新的提交。 比如： ~~~ "require": { "overtrue/wechat": "dev-master" } ~~~ 这个也是不推荐在生产环境使用的，因为它其实与 * 没有太大的差别，不过 * 在 minimum-stability 为 stable 时是安装最新的稳定版。但是二者都无法保证 API 兼容性。 ## 使用 ~ 约束符锁定小版本的方式 这种方式比较常用，也是比较安全的，比如我们希望安装 >= 1.2 并且 < 2.0 的版本时，根据语义化版本的定义，次版本号的变化是新增功能，所以 API 是稳定的，也就是可以安全更新的。 你可以写成： ~~~ "require": { "overtrue/wechat": "~1.2" } ~~~ 如果你希望次版本都不要更新，只允许修订版本（补丁版本）的变化，>= 1.1.15 并且 < 1.2.0，则写成： ~~~ "require": { "overtrue/wechat": "~1.1.15" } ~~~ 所以，你应该看出规律了，~ 的作用是允许表达式中最后一位变到最大值，~1.1 表示可以为 大于等于 1.1 的任何版本，比如 1.1.0、1.2.0、1.3.5 、1.99.9999、 1.9999.999999 都可以安装，但是不能安装 2.0.0， 同理，~1.1.2 表示 大于等于 1.1.2 的任何版本，比如 1.1.2、1.1.3、1.1.99、 1.1.9999 都可以安装。 ## 使用 ^ 约束符锁定大版本 上面 ~ 表示最后一位可变，前面几位都不可变，那 ^ 的作用不一样的是：^ 锁定不允许变的第一位，其实学过正则的同学都知道 ^ 表示起始，^a 表示以 a 开头的全部。 所以， ^1.2 表示任意大于等于 1.2 的 1.x.x 版本，比如 1.2.0、1.2.1、1.3.0、1.9.99999 等。只要前面的 1 并且大于 ^ 后面指定的 1.2 都满足条件。 ## 锁定版本范围 有时候我们的使用场景要求只能安装某些版本范围内的时候，可以使用 >、<、>=、<=、|这些符号来组合，比如：>= 1.3 <1.6、>=1.3 | >=1.7 、3.0|4.0 等。这样的使用场景并不多，根据你的情况来调整用法就好。 ## 最后就是使用具体版本号 使用 =1.2.34 或者 1.2.34 都是指定了具体的版本号， composer 不会考虑检查新版本来安装。 # 注意 如果你的版本是 1.0 以下，0.0.1，0.9.99999 等这样的版本的时候， ^ 的作用与 ~ 一样，也就是说： ^0.0.3 表示：>=0.0.3 < 0.0.4 所以需要注意这个问题，之所以这样设计是有原因的：主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。 所以不要掉进这个坑哦。 # 总结 无论你是包的作者，还是使用者，正确使用版本是非常重要的，尤其对于有一定使用量的包作者来讲，严格遵守语义化版本的规范是对你的用户负责。最后引入 semver.org 官网的一句话： 记住， 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的，那就透过版本号来向他们说明。