Семантическое обновление версии
Этот инструмент автоматизирует процесс обновления версий в Composer-проектах на основе анализа Git-коммитов и генерации CHANGELOG. Он помогает соблюдать семантическое версионирование и стандарт Conventional Commits.
👩💻 https://github.com/Voral/vs-version-incrementor
Автор: @vasoft
#semanticVersioning #versionIncrement #git #composer #changelog
Этот инструмент автоматизирует процесс обновления версий в Composer-проектах на основе анализа Git-коммитов и генерации CHANGELOG. Он помогает соблюдать семантическое версионирование и стандарт Conventional Commits.
Автор: @vasoft
#semanticVersioning #versionIncrement #git #composer #changelog
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - Voral/vs-version-incrementor: A tool for semantic versioning and changelog generation in Composer projects based on Git…
A tool for semantic versioning and changelog generation in Composer projects based on Git commits. - Voral/vs-version-incrementor
🔥4👍3
Forwarded from Alexander Vorobyev
Нужен совет/рекомендации/доводы/мысли.
Ситуация следующая: в модуль добавил больше расширяемости. И все расширения производятся через объект конфигурации. Соответственно класс конфигурации растет. Там нет сложной логики, хотя в некоторых случаях он выступает как фабрика (значения по умолчанию). В основном это конечно же просто геттеры и сеттеры.
Тем не менее scrutinizer-ci . Присвоил классу значек "F" и отображает его красным. С пояснением
Total Complexity 60 , Total Lines 827 .
Как подходить в таких случаях? Действительно ли стоит следовать его рекомендациям в таких случаях?
Подумываю разбить на трейты (по логическим группам). Сначала была мысль создавать некие классы для подобных групп - своего рода отдельные конфиги и затем их передавать в основной конфиг. Но это как то, на мой взгляд, в итоге усложнит читабельность файла конфигурации.
Речь идет вот об этом классе https://github.com/Voral/vs-version-incrementor/blob/master/src/Config.php
#semver #changelog
Ситуация следующая: в модуль добавил больше расширяемости. И все расширения производятся через объект конфигурации. Соответственно класс конфигурации растет. Там нет сложной логики, хотя в некоторых случаях он выступает как фабрика (значения по умолчанию). В основном это конечно же просто геттеры и сеттеры.
Тем не менее scrutinizer-ci . Присвоил классу значек "F" и отображает его красным. С пояснением
Total Complexity 60 , Total Lines 827 .
Как подходить в таких случаях? Действительно ли стоит следовать его рекомендациям в таких случаях?
Подумываю разбить на трейты (по логическим группам). Сначала была мысль создавать некие классы для подобных групп - своего рода отдельные конфиги и затем их передавать в основной конфиг. Но это как то, на мой взгляд, в итоге усложнит читабельность файла конфигурации.
Речь идет вот об этом классе https://github.com/Voral/vs-version-incrementor/blob/master/src/Config.php
#semver #changelog
GitHub
vs-version-incrementor/src/Config.php at master · Voral/vs-version-incrementor
A tool for semantic versioning and changelog generation in Composer projects based on Git commits. - Voral/vs-version-incrementor