给公司写的composer包开发的规范

版本格式

主版本号.次版本号.修订号

版本号递增规则

• 主版本号：当你作了不兼容的 API 修改

• 次版本号：当你作了向下兼容的功能性新增

• 修订号：当你作了向下兼容的问题修正

• 先行版本号及版本编译元数据能够加到“主版本号.次版本号.修订号”的后面，做为延伸。

发布 1.0.0 版本的时机

1. 被用于正式环境

2. 若是有个稳定的 API 被使用者依赖

3. 若是很担忧向下兼容的问题

总而言之，因为0.x版本在机制和语义上和大于1.0的版本有必定差别，容易产生误用，被用于生产环境的包的版本号都必须>=1.0

composer.lock的规范

开发应用程序必须提交 composer.lock 文件到 git 版本库中

这会确保每个人 —— 你、你的合做伙伴、你的 CI 服务器以及你的产品服务器 —— 所运行的应用程序拥有相同依赖的版本。

开发库不须要提交composer.lock

该文件对使用该库的项目不会有任何影响，没法达到限制版本的目的

composer.json中依赖版本的规范

不容许在项目中使用不限定版本的方式

因为主版本的升级可能伴随着api的不兼容，若是require * 这种不限定版本的方式极可能带来不兼容的隐患，因此推荐至少锁定主版本号

例如

目前使用xxx/service的1.0.0版本，则请写~1.0或者^1.0.0，这样效果等同于>= 1.0且< 2.0，若是第三方使用时引用了xxx/service的2.0版本且引用了你的依赖1.0的版本，则会安装出错，马上引发注意

若是 require * 则安装会正常进行，可是可能发生使用时的意外（api不兼容）

版本号锁定中^和~的重要区别

~的做用

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

 

^的做用

++^ 锁定的是x.y.z版本号中从左到右非0的第一个版本号的版本++

好比^ 1.2.3 为锁定主版本号1；而^ 0.1.2则为锁定0.1；^ 0.0.3则为锁定0.0.3版本

因此^ 的行为在>=1.0和< 1.0的状况下存在特殊状况，使用时请特别注意，

1. 版本大于1.0.0的状况

^ 锁定不容许变的第一位

 

 

2. 版本为0.x的状况

^锁定的是从左到右非0的第一个版本号的版本

 

 

• 以上是文章所有内容，有须要学习交流的友人请加入Swoole交流群的我们一块儿，有问题一块儿交流，一块儿进步！前提是你是学技术的。感谢阅读！

点此加入该群