composer 版本约束使用方法
composer 在平常的开发中是经常的使用,但是从来没有特别注意过 composer 包的版本约束,只是知道个大概,秉着活到老学到老的态度再次重新系统的学习下 composer 版本约束的具体规则。
##语义化版本
首先我们需要先了解一下语义化版本
这里有一篇介绍语义化版本的文章,有时间的小伙伴可以看一下。下面总结一下:
- 版本格式: 主版本号.次版本号.修订版本号
- 主版本号:当你做了不兼容的 API 修改,
- 次版本号:当你做了向下兼容的功能性新增,
- 修订号:当你做了向下兼容的问题修正。
- 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
示例:
1.2.34
- 1 为主版本号
- 2 为次版本号
- 34 为修订号
1.0.0-alpha1 这种在后面添加修饰符的表示先行版本。
写法
不指定版本号(使用 * 号)
一般不建议使用
1 | "require": { |
使用 * 号在进行composer 更新的时候会安装最新版本,如果第三方包的作者做了不兼容的版本的更新,那么更新后项目就跑步起来了。
使用 dev- 前缀加分支名
一般在开发包的时候会使用
1 | "require": { |
它表示使用该分支下最新的提交。
~ 符号约束小版本
这种方式比较常用
1 | "require": { |
“require”: {
“overtrue/wechat”: “^1.2”
}
1 | |
“require”: {
“overtrue/wechat”: “1.2”
}
以上内容表示必须为 1.2 的版本。
## 注意事项
如果你的版本是 1.0 以下,0.0.1,0.9.99999 等这样的版本的时候, ^ 的作用与 ~ 一样,也就是说:
^0.0.3 与 ~0.0.3 一样,都表示:>=0.0.3 < 0.0.4
因为主版本号为零(0.y.z)的软件一般处于开发初始阶段,一切都可能随时被改变。
## 结论
通过上面的学习我们知道了语义化版本的重要性,composer 在执行 update 的时候会根据我们定义的版本约束进行升级,如果我们使用的第三方包没有按照语义化版本来定义版本号,那么在升级之后就会出现项目无法运行的情况。所以我们在使用第三方的包的时候一定要注意该包是否使用语义化版本来定义版本号(不知道怎么选的,一般选择用得人比较多的第三方包)。在有一点就是我们自己在开发扩展包的时候也需要安装语义化版本来定义扩展包的版本号。

composer 版本约束使用方法
http://blog.xiangdangnian.net.cn/2020/09/15/composer版本约束使用方式/