[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 官網的一句話： 記住， 語義化的版本控制就是透過版本號的改變來傳達意義。若這些改變對你的使用者是重要的，那就透過版本號來向他們說明。