如果你還不知道 composer，請前往composer使用教程欄目然后開始閱讀吧。
我曾見過許多人被他們使用的 composer 包之間依賴的約束問題所困擾。希望這篇文章能指出某些問題的原因，并提供避免這些問題的方法。我會從最糟的情景入手，并一步步改進約束。
全能的星號：*
Composer 有一個依賴解析器，所以它能夠自動的找出我想要的，對嗎？錯。
用 * 聲明一個版本約束可能是最糟糕的做法之一。因為你絕對無法控制你會得到什么。它可能是 任何 匹配 minimum-stability 和其它約束的版本。
基本上你就相當于在和 Composer 玩一個 俄羅斯輪盤賭 游戲，最終你會被它傷害到。然后你就可能會責怪這個工具太令你失望了。
如果你繼續粗心大意，請最起碼依賴最新的開發版本，通常被標記為 dev-master。
寫死的分支名稱
所以你現在在使用 dev-master。問題在于，dev-master 所指向的代碼可能會更改。至少，你獲取的總是不穩定的包（從 composer 所表征的穩定性標志來看不穩定）。然而，更大的問題在于，dev-master 的意義可能隨時會變。
比方說，現在它所表示的是最新的 1.0 開發版本。當開發者說他們要開始開發 1.1 版本的時候，dev-master 這個分支名字不再指向 1.0 分支，它開始指向最新的 1.1 開發分支。
除非你緊密關注著該庫的開發，否則，直到你運行了 composer update 命令時，問題才會顯示在你面前，然后毀了你一整天。因此，直接引用分支的名稱并不是一個可持續的解決方案。幸運的是，在別名的問題上，composer 可以提供幫助。
分支別名
分支別名作為一個屬性，包維護者可以將其放到他們的 composer.json 里面，允許這些分支名稱映射到版本上。
像 1.0 ， 2.1 等等分支名稱并不是必須的， Composer 已經對這些進行了處理。
但是像 master 這樣的分支名稱會產生一個名為 dev-master 的版本，你一定要給它別名。 Composer 文檔里面有 一個不錯的關于別名的文章 ，里面解釋了如何定義分支別名：
{ ????"extra":?{ ????????"branch-alias":?{ ????????????"dev-master":?"1.0.x-dev" ????????} ????} }
dev-master 版本會映射到一個 1.0.x-dev 的別名上，
這基本上意味著你可以用一個 1.0.*@dev 的約束來要求包。這樣的好處是 1.0 的含義會被定義，且不會改變。 它也將使切換到穩定版本更容易。
分支別名的警告需要包維護者將它們放入。如果使用的是沒有分支別名的庫，則向它們發送一個上拉請求，將上面的 extra 部分添加到它們的 composer.json 中。
穩定版本
1.0.*@dev 這個約束已經很不錯了。但問題是到目前為止，仍然還沒有一個穩定的版本。除了你仍然運行著一個不穩定的版本這個事實之外，你的代碼并沒有什么問題。
但是如果別人的項目依賴了你的包，那么你的用戶需要明確地使用 @dev 標識來允許 Composer 安裝不穩定的版本，或者干脆降低項目 minimum-stability 的等級，這意味著他們將獲得 所有依賴包 的不穩定版本。
避免開發版本不穩定性的最好方法就是打上 release 標簽（指發布穩定版本）。 如果你正在使用一個沒有打上 release 標簽的庫，提醒它的維護者直到打上標簽。現在就做！
作為 Composer 社區的一份子，我們要有責任心。 我們必須發布穩定的版本，并且應該維護好 CHANGELOG （更新日志）。 這很不容易，但是這將讓整個生態系統發生巨大的改變。記住，如實地、 語義化 地來打標簽。
當你發布了一個穩定的版本，你就能去掉 @dev 標識并且將你的約束改為 1.0.* 。
下一個重大版本
如果你所依賴的包的每一個發布節點都堅持遵守語義化版本的規則，并且嚴格向后兼容，那么你就可以逐漸提高約束。
現在 1.0.* 版本有一些潛在的兼容性問題，并很快發布了 1.1 版本。如果你的約束是 1.0 ，但是別人需要 1.1 版本的新特性（還記得向后兼容嗎？）， 他們就不能安裝 1.1 版本。所以你需要重寫你的約束，比如： 1.* 。
好極了，除非你開始依賴 1.1 版本的新特性，否則你不必修改約束，它將會仍然匹配 1.0 這個沒有新特性的版本。
接著，你修改約束為 >=1.1,
TLDR
使用 branch-alias。
標簽發布，使發布更可靠和 符合語義.
使用 ~ 運算符。
