composer 版本约束使用方法

composer 在平常的开发中是经常的使用,但是从来没有特别注意过 composer 包的版本约束,只是知道个大概,秉着活到老学到老的态度再次重新系统的学习下 composer 版本约束的具体规则。

##语义化版本

首先我们需要先了解一下语义化版本

这里有一篇介绍语义化版本的文章,有时间的小伙伴可以看一下。下面总结一下:

  • 版本格式: 主版本号.次版本号.修订版本号

  • 主版本号:当你做了不兼容的 API 修改,

  • 次版本号:当你做了向下兼容的功能性新增,

  • 修订号:当你做了向下兼容的问题修正。

  • 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

示例:

1.2.34

  • 1 为主版本号

  • 2 为次版本号

  • 34 为修订号

1.0.0-alpha1 这种在后面添加修饰符的表示先行版本。

写法

不指定版本号(使用 * 号)

一般不建议使用


"require": {

"overtrue/wechat": "*"

}

使用 * 号在进行composer 更新的时候会安装最新版本,如果第三方包的作者做了不兼容的版本的更新,那么更新后项目就跑步起来了。

使用 dev- 前缀加分支名

一般在开发包的时候会使用


"require": {

"overtrue/wechat": "dev-master"

}

它表示使用该分支下最新的提交。

~ 符号约束小版本

这种方式比较常用


"require": {

"overtrue/wechat": "~1.2"

}

以上内容表示安装 >= 1.2 且 <2.0 的版本。(1.3、1.4、1.5等 不大于 2.0 的版本)

如果写成 “~1.2.3”,该约束表示 >=1.2.3 且 <1.2 (1.2.3、1.2.4、1.2.5 不大于 1.2 的版本)

~ 的作用是允许表达式中最后一位变到最大值

^ 符号约束大版本

这种方式也比较常用


"require": {

"overtrue/wechat": "^1.2"

}

以上内容表示可以安装 >=1.2 且 <2.0.0 版本。

如果写成 “^1.2.3” 则表示 >=1.2.3 且 <2.0.0 版本。

也就是说 ^ 锁定不允许变的第一位

锁定版本范围

有时候我们的使用场景要求只能安装某些版本范围内的时候,可以使用 >、<、>=、<=、| 这些符号来组合,比如:>= 1.3 <1.6、>=1.3 | >=1.7 、3.0|4.0 等。这样的使用场景并不多,根据你的情况来调整用法就好。

锁定具体版本


"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 的时候会根据我们定义的版本约束进行升级,如果我们使用的第三方包没有按照语义化版本来定义版本号,那么在升级之后就会出现项目无法运行的情况。所以我们在使用第三方的包的时候一定要注意该包是否使用语义化版本来定义版本号(不知道怎么选的,一般选择用得人比较多的第三方包)。在有一点就是我们自己在开发扩展包的时候也需要安装语义化版本来定义扩展包的版本号。

程序员的艺术人生

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!