Восхитительное чувство, когда один раз взглянув на новую версию сторонней библиотеки ты понимаешь, можно ли её смело обновлять или нужно быть готовым к изменениям в собственном коде. В сухую нумерацию пакетов вносит осмысленность Семантическое Версионирование. У семантического версионирования есть свой сайт и основные посылы я брал оттуда (ссылка в конце статьи).

Основная Идея

Существует основной формат:

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 которых будут взаимодействовать другие команды. Всё это отличные примеры того, где семантическое версионирование преобретает смысл. Семантическое версионирование - это язык, в трёх словах которого общаются независимые проекты.

Сайт Семантического Версионирования

comments powered by Disqus