當你使用 VCS 資源庫,你將只會得到類似于這樣的版本號:從分支發(fā)布的標簽獲取,它看起來像 2.0
或 2.0.x
。比較特殊的是,對于你的 master
分支,你會得到一個最新提交的 dev-master
版本。對于你的 bugfix
分支,你會得到一個最新提交的 dev-bugfix
版本。以此類推,這些特殊的版本標識可以用來獲取最新的分支源碼。
如果你的 master
分支使用標簽發(fā)布了 1.0
系列版本,即 1.0.1
、1.0.2
、1.0.3
等等,任何依賴它的資源包都可能會使用 1.0.*
這個版本約束。
如果有人想要最新的 dev-master
版本,他們將會碰到一個問題:另一些依賴它的包可能使用了 1.0.*
這個版本約束,因此在 require 這個開發(fā)版本時將會產(chǎn)生沖突,因為 dev-master
不符合 1.0.*
的約束。
這時,就可以使用別名。
dev-master
指向一個在你 VCS 項目上的主分支。有些用戶會想要使用最新的開發(fā)版本,這是相當常見的情況。因此,Composer 允許你別名你的 dev-master
版本為一個 1.0.x-dev
的版本號。這是通過在 composer.json
文件中的 extra
下指定 branch-alias
字段來完成的:
{
"extra": {
"branch-alias": {
"dev-master": "1.0.x-dev"
}
}
}
此處的分支版本必須以 dev-
開頭(不可比較的版本名稱),對應(yīng)的別名必須是可比較的開發(fā)版本名稱(即,以數(shù)字開頭,并以 .x-dev
結(jié)束)。branch-alias
所引用的分支必須是存在的。對于 dev-master
你需要在 master
分支上提交它。
其結(jié)果是,任何人都可以使用 1.0.*
版本約束來得到 dev-master
版本。
為了定義分支別名,你必須是需要別名的包的所有者。如果你想別名一個第三方包,而又不想 fork 它到自己的版本庫,可以使用行內(nèi)別名,我們在接下來就會提到它。
分支別名是非常適合用于主開發(fā)分支的。但為了使用它們,你需要擁有對源碼的控制權(quán),并且你需要提交別名修改到你控制的版本庫。
當你只想在本地項目中嘗試一些依賴包的 bug 修正時,這并不是最好的方式。
出于這個原因,你可以在 require
和 require-dev
字段中直接別名你需要的包。比方說那你找到了 monolog/monolog
的一個 bug。你在 GitHub 上克隆了 Monolog 并在名為 bugfix
的分支上修正了一個問題?,F(xiàn)在你想安裝這個版本到你的本地項目。
你所使用的 symfony/monolog-bundle
require 了 monolog/monolog
并約束了版本 1.*
. 因此你需要讓你的 dev-bugfix
滿足該版本約束。
只要在你項目根目錄的 composer.json
文件中加入以下內(nèi)容:
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/you/monolog"
}
],
"require": {
"symfony/monolog-bundle": "2.0",
"monolog/monolog": "dev-bugfix as 1.0.x-dev"
}
}
它將會在你的 GitHub 上獲取 monolog/monolog
的 dev-bugfix
版本并將其版本別名為 1.0.x-dev
。
注意: 如果要對一個資源包使用行內(nèi)別名,這個別名(
as
的右邊)必須能夠使用版本約束。as
左邊的部分在這之后將被丟棄。因此,如果 A 依賴 B 而 B 又依賴monolog/monolog
且版本約束為dev-bugfix as 1.0.x-dev
,那么安裝 A 時將使用 B 的版本約束,并識別為1.0.x-dev
,此時必須真實存在一個“分支別名”或“1.0 系列分支”。否則就必須在 A 的composer.json
文件中再次定義行內(nèi)別名。注意: 應(yīng)該盡量避免行內(nèi)別名,特別是對已經(jīng)發(fā)布的包。如果你發(fā)現(xiàn)了一個 bug,請嘗試將你的修復(fù)合并到上游分支。這將避免使用你資源包的用戶出現(xiàn)問題。
更多建議: