Восхитительное чувство, когда один раз взглянув на новую версию сторонней библиотеки ты понимаешь, можно ли её смело обновлять или нужно быть готовым к изменениям в собственном коде. В сухую нумерацию пакетов вносит осмысленность Семантическое версионирование. У семантического версионирования есть свой сайт и основные посылы я брал оттуда (ссылка в конце статьи).
Основная идея
Существует основной формат:
MAJOR.MINOR.PATCH
Формат включает в себя три неотрицательные цифры, которые увеличиваются в соответствии со следующими условиями.
MAJOR — увеличение версии говорит об обратно несовместимых изменениях API.
MINOR — увеличение версии говорит о добавлении новой функциональности при сохранении обратной совместимости.
PATCH — увеличение версии говорит об обратно совместимых фиксах.
Какую проблему решаем?
При большом количестве зависимостей в вашем проекте может встать вопрос о потребности в использовании новых версий разных библиотек. Если дать полную свободу в версионировании, то процесс превратится в настоящий ад, т.к. становится абсолютно не очевидно сломает ли всё, например, переход с версии 2.3.4 на версию 2.6.8. Идея не новая, но её формализация позволяет всем использовать и понимать версии одинаково.
Как решаем?
Основная идея была описана выше, а ниже некоторые, на мой взгляд, важные вещи из спецификации SemVer.
- если какие-то изменения сделаны после релиза, то они попадут только в новый релиз;
- публичный API для версии 0.х.х не должен рассматриваться как стабильный, это версия для начальной разработки;
- версия 1.0.0 определяет публичный API;
- если часть API помечена “устаревшей”, то инкрементируем минорную версию, в том числе она может в себя включать фиксы;
- мажорная версия может включать в себя изменения характерные минорной версии и патчу;
- версию можно дополнять указателями на предрелизные выпуски или сборками изменяющими метаданные, но идентификаторы версий только в ASCII.
Всегда ли это подходит?
Нет, не всегда. Если вы разрабатываете программу/веб приложение для конечного пользователя, а не библиотеку или http API, то скорее всего семантическое версионирование вам не нужно. Прежде всего, посмотрите на цели и статус вашего проекта, возможно он находится на поддержке, всё, что вы делаете, — исправляете ошибки, то есть “новая функциональность” не появляется, это значит, что первые две цифры будут вечно неизменными, тогда какой в этом смысл? С другой стороны, если взглянуть категорично, то так и должно быть, каждый раз закрывая пачку багов, вы обновляете PATCH версию, а при необходимости хот-фиксов просто расширяете её дополнительными идентификаторами.
Для кого это подходит?
Иногда, мы пишем библиотеки, иногда мы пишем модули от которых будет зависеть остальная часть системы, иногда мы пишем микросервисы с API которых будут взаимодействовать другие команды. Всё это отличные примеры того, где семантическое версионирование преобретает смысл. Семантическое версионирование — это язык, в трёх словах которого общаются независимые проекты.
Сайт семантического версионирования
Автор: Roman Brovko
