Версии

1. Версии композитора и версии VCS
2. Теги и ветви VCS
   1. Теги
   2. Ветви
   3. Минимальная стабильность
3. Написание ограничений базовой версии
   1. Точный
   2. Ассортимент
   3. Диапазон (дефис)
   4. Подстановочный знак
4. Следующие значимые операторы деблокирования
   1. Тильда
   2. Каретка
5. Ограничения стабильности
6. Ограничения тестовой версии

Версии composer и Версии #

Поскольку Composer в большой степени ориентирован на использование систем контроля версий, таких как git, термин «версия» может быть немного двусмысленным. В смысле системы управления версиями «версия» представляет собой определенный набор файлов, содержащих конкретные данные. В терминологии git это «ref» или конкретный коммит, который может быть представлен веткой HEAD или тегом. Когда вы проверяете эту версию в своей VCS - например, тег v1.1 или фиксатор e35fa0d--, вы запрашиваете один известный набор файлов, и вы всегда получаете те же файлы обратно.

В Composer, что часто называют небрежно версией, то есть строка, следующая за именем пакета в строке require (например, ~1.1 или 1.2.*), На самом деле является скорее ограничением версии. Composer использует ограничения версии, чтобы выяснить, какие ссылки в VCS должны быть проверены (или просто убедиться, что данная библиотека приемлема в случае статически поддерживаемой библиотеки со спецификацией version в composer.json).

VCS Теги и филиалы #

Для дальнейшего обсуждения предположим следующий репозиторий библиотеки:

~/my-library$ git branch
v1
v2
my-feature
nother-feature

~/my-library$ git tag
v1.0
v1.0.1
v1.0.2
v1.1-BETA
v1.1-RC1
v1.1-RC2
v1.1
v1.1.1
v2.0-BETA
v2.0-RC1
v2.0
v2.0.1
v2.0.2

Теги #

Обычно Composer работает с тегами (в отличие от ветвей - если вы не знаете, что это значит, ознакомьтесь с системами контроля версий). Когда вы пишете ограничение версии, оно может ссылаться на определенный тег (например, 1.1) или ссылаться на допустимый диапазон тегов (например,>=1.1 <2.0 или ~4.0). Чтобы устранить эти ограничения, Composer сначала попросит VCS перечислить все доступные теги, а затем создаст внутренний список доступных версий на основе этих тегов. В приведенном выше примере внутренний список композитора включает версии 1.0, 1.0.1, 1.0.2, бета-версию 1.1, первый и второй кандидаты версии 1.1, окончательную версию 1.1 и т. Д .... (Обратите внимание, что Composer Автоматически удаляет префикс 'v' в фактическом тэге, чтобы получить действительный окончательный номер версии.)

Когда Composer имеет полный список доступных версий вашего VCS, он находит самую высокую версию, которая соответствует всем ограничениям версии вашего проекта (возможно, что другие пакеты требуют более определенных версий библиотеки, чем вы, поэтому выбранная версия может Не всегда является наивысшей доступной версией), и он загружает zip-архив этого тега, чтобы распаковать его в нужном месте каталога вашего vendor.

Ветви #

Если вы хотите, чтобы Composer проверял ветвь вместо тега, вам нужно указать ее ветке, используя специальный префикс dev-* (или иногда суффикс, см. Ниже). Если вы проверяете ветку, предполагается, что вы хотите работать над веткой, и Composer фактически клонирует репозиторий в нужное место в вашем каталоге vendor. Для тегов он просто копирует нужные файлы без фактического клонирования репо. (Вы можете изменить это поведение с помощью -prefer-source и -prefer-dist, см. Параметры установки.)

В приведенном выше примере, если вы хотите проверить ветвь my-feature, вы должны указать dev-my-feature как ограничение версии в вашем предложении require. Это приведет к тому, что Composer клонирует репозиторий my-library в мой каталог поставщиков и проверяет ветвь my-feature.

Когда имена ветвей выглядят как версии, мы должны уточнить для композитора, что мы пытаемся проверить ветвь, а не тег. В приведенном выше примере у нас есть две ветви версии: v1 и v2. Чтобы получить Composer, чтобы проверить одну из этих ветвей, вы должны указать ограничение версии, которое выглядит так: v1.x-dev. .x - это произвольная строка, которую Composer требует сообщить, что мы говорим о ветке v1, а не теге v1 (альтернативно, вы можете просто назвать ветвь v1.x вместо v1). В случае ветки с похожим на версию названием (v1, в данном случае), вы добавляете -dev в качестве суффикса, вместо использования dev- в качестве префикса.

Минимальная стабильность #

Есть еще одна вещь, которая повлияет на то, какие файлы будут извлечены из VCS библиотеки и добавлены в ваш проект: Composer позволяет вам указать ограничения стабильности, чтобы ограничить, какие теги считаются допустимыми. В приведенном выше примере обратите внимание, что библиотека выпустила бета-версию и два релиза-кандидата для версии 1.1 перед окончательным официальным выпуском. Чтобы получать эти версии при composer install или composer update, мы должны явно указать Composer, что у нас все в порядке с кандидатами на выпуск и бета-релизами (и альфа-релизами, если мы этого хотим). Это можно сделать, используя значение minimum-stability для всего проекта в composer.json или используя флаги стабильности в ограничениях версии. Подробнее читайте статью Схемы.

Написание ограничений базовой версии #

Теперь, когда у вас есть представление о том, как Composer видит версии, давайте поговорим о том, как указать ограничения версии для ваших зависимостей проекта.

Точный #

Вы можете указать точную версию пакета. Это сообщит Composer установить эту версию и эту версию. Если для других зависимостей требуется другая версия, решатель, в конечном счете, откажется и прервет любые процедуры установки или обновления.

Пример: 1.0.2

Ассортимент #

С помощью операторов сравнения вы можете указать диапазоны допустимых версий. Допустимые операторы: >, >=, <, <=, !=.

Можно задать несколько диапазонов. Диапазоны, разделенные пробелом ( ) или запятой (,), будут рассматриваться как логическое И. Двойной канал (||) будет рассматриваться как логическое ИЛИ. И имеет более высокий приоритет, чем OR.

Примечание. Будьте осторожны при использовании неограниченных диапазонов, так как вы можете неожиданно установить версии, нарушающие совместимость. Вместо этого используйте безопасный оператор каретки.

Примеры:

• >=1.0
• >=1.0 <2.0
• >=1.0 <1.1 || >=1.2

Диапазон (дефис) #

Включительный набор версий. Частичные версии справа включают в себя подстановочный знак. Например, 1.0 - 2.0 эквивалентен >=1.0.0 <2.1, так как 2.0 становится 2.0.*. С другой стороны, 1.0.0 - 2.1.0 эквивалентен >=1.0.0 <=2.1.0.

Пример: 1.0 - 2.0

Подстановочный знак #

Вы можете указать шаблон с * подстановочным знаком. 1.0. * Эквивалентно> = 1.0 <1.1.

Пример: 1.0. *

Следующие значимые операторы деблокирования #

Тильда #

Оператор ~ лучше всего объясняется примером: ~1.2 эквивалентен >=1.2 <2.0.0, тогда как ~1.2.3 эквивалентен >=1.2.3 <1.3.0. Как видите, это в основном полезно для проектов, связанных с семантическим версированием. Чаще всего вы отмечаете минимальную минорную версию, от которой вы зависите, например ~1.2 (что позволяет делать что угодно, но не включая 2.0). Так как в теории не должно быть обратных перерывов в совместимости до 2.0, что хорошо работает. Другим способом рассмотрения является то, что использование ~ указывает минимальную версию, но позволяет последней указанной цифре увеличиваться.

Пример: ~1.2

Примечание.Несмотря на то, что 2.0-beta.1 находится строго перед 2.0, ограничение версии, например ~1.2, не будет устанавливать его. Как сказано выше ~1.2 означает только, что .2 может измениться, но часть 1. фиксирована.

Примечание.Оператор ~ имеет исключение из своего поведения для основного номера выпуска. Это означает, например, что ~1 - это то же самое, что ~1.0, поскольку это не позволит увеличить число, пытаясь сохранить обратную совместимость.

Карет #

Оператор ^ ведет себя очень похоже, но он более близок к семантическому версированию, и всегда будет разрешать неразрывные обновления. Например, ^1.2.3 эквивалентен >=1.2.3 <2.0.0, так как ни одна из версий до 2.0 не должна нарушать совместимость с предыдущими версиями. Для версий до 1.0 он также действует с учетом безопасности и рассматривает ^0.3 как >=0.3.0 <0.4.0.

Это рекомендуемый оператор для максимальной функциональной совместимости при написании кода библиотеки.

Пример: ^ 1.2.3

Ограничения стабильности #

Если вы используете ограничение, которое не определяет явную стабильность, Composer по умолчанию будет использовать внутреннее значение -dev или -stable, в зависимости от используемого оператора(ов). Это происходит прозрачно.

Если вы хотите явно рассматривать только стабильный выпуск в сравнении, добавьте суффикс -stable.

Примеры:

Однако для обеспечения различной стабильности, не применяя их на уровне ограничений, вы можете использовать флаги стабильности, такие как @ (например, @dev), чтобы композитор знал, что данный пакет может быть установлен в другой стабильности, чем ваша минимальная стабильность по умолчанию Установка. Все доступные флаги стабильности перечислены в разделе минимальной стабильности в статье Схемы.

Ограничения тестовой версии #

Вы можете проверить ограничения версии, используя semver.mwl.be. Заполните имя пакета, и оно автоматически выполнит ограничение по умолчанию, которое Composer добавит в ваш файл composer.json. Вы можете настроить ограничение версии, и инструмент выделит все выпуски, которые соответствуют.