Добавлен функционал тегов

[sn-chernyshev]

Добавил функционал тегов #154

[andreyryabin]

Добавляя новое свойство protected $tag мы потенциально можем сломать пользовательские миграции, если они такое свойство объявляли у себя.

Можно назвать protected string $versionTag и будет чуть лучше, правильный нейминг и тип тут очень важен, так как от этого класса наследуются все миграции.

Основная загвоздка тут в смешении понятий вашего тега, в файле класса и тега в базе данных.
Тег который ставится в бд - тег релиза, нужен чтобы промаркировать миграции во время деплоя
и откатить их по этому тегу если релиз окажется неудачным.

Ваш тег скорее группирует миграции по этому признаку, и непосредственно с релизом не связан.

Получается неочевидное поведение, когда во время установки, вы тег из файла записываете в бд как тег релиза.

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

Надо поразмышлять на тему, как должен отображаться такой тег релиза, когда миграция еще не установлена и релиз еще не случился.

[sn-chernyshev]

Добавляя новое свойство protected $tag мы потенциально можем сломать пользовательские миграции, если они такое свойство объявляли у себя.

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

По добавлению типа согласен, можно добавить что это string. С неймингом как раз не понятно почему versionTag. Т.е. тег версии, какой версии, самого модуля или чего?

Ваш тег скорее группирует миграции по этому признаку, и непосредственно с релизом не связан.

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

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

Да, этого как раз и добивался, чтобы тег можно было задать при создании миграции и чтобы он установился при применении миграции.

[sn-chernyshev]

При моих изменениях теперь возможно автоматическое применение миграций, например при смене ветки на площадке.
Т.е. в интерфейсе выбираем нужную ветки в гите (например ветку задачи) применяем её, а также применяются все нужные миграции (например так php migrate.php up --tag=branch_name). Если нужно перейти на другую ветку задачи, то соответственно отменяем миграции текущей ветки (например так php migrate.php down --tag=branch_name) и переходим на нужную ветку и опять применяем нужные миграции.

Данный функционал позволит, например тестировщикам проверять конкретные ветки задач на площадке тестирования.

[sn-chernyshev]

Добавил тип свойства $tag