給公司寫的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交流羣的我們一塊兒，有問題一塊兒交流，一塊兒進步！前提是你是學技術的。感謝閱讀！

點此加入該羣