- Почему псевдонимы?
- Алиас ветви
- Требовать встроенный псевдоним
Почему псевдонимы? #
Когда вы используете репозиторий VCS, вы получите только сопоставимые версии для ветвей, которые выглядят как версии, такие как 2.0 или 2.0.x. Для вашей master ветки вы получите версию dev-master. Для вашей ветви bugfix вы получите версию dev-bugfix.
Если ветка master используется для отметки выпусков версии 1.0, то есть 1.0.1, 1.0.2, 1.0.3 и т. Д., Любой пакет, зависящий от него, вероятно, потребует версии 1.0.*.
Если кто-то хочет заполучить последнюю версию dev-master, у них есть проблема: для других пакетов может потребоваться 1.0.*, Поэтому требующая, чтобы версия dev привела к конфликтам, поскольку dev-master не соответствует ограничению 1.0.*.
Введите псевдонимы.
Алиас ветви #
Филиал dev-master - один в вашем основном репозитории VCS. Довольно часто кто-то хочет последнюю версию dev. Таким образом, Composer позволяет вам присвоить своей ветви dev-master версию 1.0.x-dev. Это делается путем указания поля branch-alias под extra в composer.json:
{
"extra": {
"branch-alias": {
"dev-master": "1.0.x-dev"
}
}
}
Если вы являетесь псевдонимом несопоставимой версии (например, dev-develop), префикс dev- должен указывать имя ветви. Вы также можете сопоставить сопоставимую версию (т.e. начинать с номеров и заканчивать с .x-dev), но только в качестве более конкретной версии. Например, 1.x-dev может быть сгенерирован как 1.2.x-dev.
Псевдоним должен быть сопоставимой версией dev, а branch-alias должен присутствовать в ветви, на которую он ссылается. Для dev-master вам нужно зафиксировать его на ветке master.
В результате каждый теперь может потребовать 1.0.*, И он с радостью установит dev-master.
Чтобы использовать псевдонимы ветвей, вы должны владеть репозиторием пакета, на который наложен псевдоним. Если вы хотите создать псевдоним стороннего пакета без поддержки его вилки, используйте встроенные псевдонимы, как описано ниже.
Требовать встроенный псевдоним #
Алиасы ветвей отлично подходят для наложения основных линий разработки. Но чтобы использовать их, вам необходимо иметь контроль над исходным репозиторием, и вам нужно зафиксировать изменения в управлении версиями.
Это не очень весело, когда вы просто хотите попробовать исправление некоторой библиотеки, зависящей от вашего локального проекта.
По этой причине вы можете создавать псевдонимы в своих полях require и require-dev. Допустим, вы нашли ошибку в пакете monolog/monolog. Вы клонировали Monolog на GitHub и исправили ошибку в ветке с именем bugfix. Теперь вы хотите установить эту версию монолога в своем локальном проекте.
Вы используете symfony/monolog-bundle, для которого требуется monolog/monolog версии 1.*. Таким образом, вам нужно, чтобы ваше dev-bugfix соответствовало этому ограничению.
Просто добавьте это в свой проект composer.json:
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/you/monolog"
}
],
"require": {
"symfony/monolog-bundle": "2.0",
"monolog/monolog": "dev-bugfix as 1.0.x-dev"
}
}
Это приведет к извлечению версии monolog/monolog для dev-bugfix из вашего GitHub и присвоит его 1.0.x-dev.
Примечание. Если требуется пакет с встроенными псевдонимами, в качестве ограничения версии используется псевдоним (справа от as). Оставленная часть отбрасывается. Как следствие, если A требует B и B требует версии monolog/monolog dev-bugfix as 1.0.x-dev, установка A заставит B потребовать 1.0.x-dev, которая может существовать как ветвь псевдонима или фактическая ветка 1.0. Если это не так, он должен быть in-inline-aliased в composer.json.
Примечание. Следует избегать использования встроенного алиасинга, особенно для опубликованных пакетов. Если вы нашли ошибку, попробуйте установить исправление в восходящий поток. Это помогает избежать проблем для пользователей вашего пакета.
|