composer Как выпустить новую версию бандла (пакета)

Если у вас есть свой собственный пакет в разработке, рано или поздно вас заинтересует вопрос, как оформить вносимые изменения и оповестить о них пользователей. В этой статье рассмотрим, что нужно делать.

Как обозначается версия бандла. Что значат её части

В общем виде версия пакета выглядит так:

<major>.<minor>.<patch>

Когда же следует менять каждую из них?

  • Мажорная: сделаны существенные изменения, ломающие обратную совместимость
  • Минорная: добавлена новая функциональность, не нарушающая обратной совместимости
  • Патч-версия: внесены мелкие исправления или доработки, не нарушающие обратной совместимости

Как выпустить новую версию бандла

Версия пакета указывается в его composer.json

{
    "name": "brand/calendar-bundle",
    "version": "0.1.0",
    ...
}

Для локальной разработки этого будет достаточно, но обычно Composer загружает пакет из удаленного git-репозитория. Чтобы понять, где искать нужную версию каждый релиз должен быть помечен тегом в формате соответствующей версии. Например:

git tag v0.1.0

После того как вы запушите обновленный composer.json и новый тег в удаленный репозиторий — composer сможет обнаружить новую версию.

Обобщая вышесказанное:
- вносим изменения в бандл
- пушим их в мастер в git
- создаём тег (привязывается к комиту, см ниже) и также пушим его в git

Чтобы composer понял, что появилась новая версия, создаём тег

Посмотреть список имеющихся тэгов можно так:

git tag

или найти только соответствующие шаблону:

git tag -l "v1.8*"

Создание тегов

Теги бывают двух видов: легковесные и аннотированные.
Легковесный тег — это просто указатель на определённый коммит.

А вот аннотированные теги хранятся в базе данных Git как полноценные объекты. Они имеют контрольную сумму, содержат имя автора, его e-mail и дату создания, комментарий.

Рекомендуется создавать аннотированные теги, но если вы хотите сделать метку временно или по какой-то причине не хотите сохранять остальную информацию, то годятся и легковесные.

Итак, создать аннотированный тег можно так:

git tag -a v0.1.1 -m "my version 0.1.1"

где v0.0.1 - имя тега, а "my version 0.1.1" - комментарий

команда git show покажет все данные тега по его имени:

git show v0.1.1
tag v0.1.1
Tagger: John Stab <j@stab.cc>
Date:   Sat April 3 20:19:12 2021 -0700

my version 1.0.1

commit ca82a6dff817ec66f44342007202690a93763949
Author: John Stab <jstab@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2021 -0700

    Change version number

Создать легковесную метку можно так:

git tag v0.1.1-lw

Как обозначить ожидаемую версию бандла в проекте пользователя

В composer.json приложения добавить:

"require": {
    "brand/calendar-bundle": "^0.1.0",
    ...
},

Знак ^ перед версией разрешает composer загружать все версии бандла, не ломающие обратную совместимость:

Для версий > 1.0.0 такими будут считаться все патч и минорные версии вплоть до 2.0.0.
В нашем случае подойдут все версии до 1.0.0 не включая саму 1.0.0

Как подтянуть изменения в проектах пользователей

Если в репозитории бандла произошли изменения, то просто выполните composer update в своём проекте. Composer сверит последний выкаченный коммит и то, что в репозитории и подтянет изменения.

Источники

vedro-compota's picture

  1. Изменил подшивку на подсправочник композера
  2. Та же идея в заметке "релиза" в git: http://fkn.ktu10.com/?q=node/9823
  3. Для подтягивания версии конкретного пакета лучше обновлять конкретно его (composer update имяпакета), а не все и сразу composer update
  4. Заметка по версиям есть тут

_____________
матфак вгу и остальная классика =)

melisa's picture

  1. пыталась найти справочник композера поиском, почему-то не вышла на него
  2. действительно, есть такое)