самое простое - семантические релизы. определяете перечень веток, на которых происходит триггер на версионирование например, на semantic-release по дефолту branches: [ "+([0-9])?(.{+([0-9]),x}).x", "master", "next", { name: "alpha", prerelease: true }, { name: "beta", prerelease: true }, ], при вливании фича-ветки в одну из этих веток, тег считается взависимости от предыдущего тега до последнего коммита. анализатор коммитов в зависимости от вашего конфига читает тип и сообщение коммита (они должны быть формализованы и записываться согласно правилам, это контролируется линтером коммита), считаем, что fix тип увеличивает патч-версиь, feat тип - минорную, broken changes - меняет мажор например, есть тег 1.0.0, новая ветка сливается и в ней есть такой хвост от последнего тега fix: ololol feat: test ci: azazaaza новая версия - 1.1.0 или fix: ololol fix: test ci: azazaaza новая версия - 1.0.1 все идет от ветки мастер, на ней висят теги, она главная
бамп мажорнойда и минорной версии чисто продуктовое решение бывает, маркетиноговое, какая обратная совмемтимость в продукте?
что значит обратная совместимость?
для пользовательского продукта - не знаю )
Обсуждают сегодня