Пост

Версионирование кода

Рассмотрим соглашение о версиях кода простым языком

Версионирование кода

Семантическое версионирование кода - это некое формальное соглашение по которому определяются номера версий для новых выпусков программного обеспечения.

Исходный документ https://semver.org/lang/ru/

Что такое версия

Версия программы - это три цифры 0.0.0. Так же могут быть и другие символы.

Рассмотрим составляющие части версии:

Major

1.0.0

Мажорная версия или основной номер версии.

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

В таких случаях говорят, что версия 1.0.0 и версия 2.0.0 обратно несовместимы.

Это совершенно не значит, что версия 2.0.0 лучше версии 1.0.0, это просто разные версии одного продукта.

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

Minor

1.0.0

Дополнительный номер версии или минорный номер версии.

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

Patch

1.0.0

Номер исправления или Патч версия.

Ее меняют когда изменение незначительное, которое не влияет на функционал пакета.

Ее можно устанавливать всегда, так как это исправление ошибок.

Дерево версии

Версию можно смоделировать в виде дерева

1
2
3
Мажорная версия
    Минорная версия
        Патч версия

Каждая мажораная версия при этом может иметь свой набор минорных версий, которая в свою очередь наборы патч версий.

Примеры версий

1
2
3
0.1.1
1.2.34
2.0.45

Особенности

Увеличение версии

Каждый элемент версии в цепочке должен увеличиваться целочисленно, например:

  • 1.0.0 - Выпуск первой версии пакета
  • 1.0.1 - Баг фикс в первой версии пакета
  • 1.1.0 - Новая функция в первой версии пакета
  • 1.2.0 - Новая функция в первой версии пакета
  • 1.2.1 - Баг фикс в первой версии пакета
  • 1.2.2 - Еще один Баг фикс в первой версии пакета
  • 1.3.0 - Добавление новой фичи в первую версию пакета
  • 2.0.0 - Выпуск второй версии пакета
  • 2.0.1 - Баг фикс второй версии
  • 2.1.0 - Новая функциональность второй версии
  • 3.0.0 - Третья версия пакета

Тут можно видеть, что версии не растут линейно, а учитывают добавленный функционал.

Зафиксированный релиз

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

Начало разработки и стабильный релиз

Пока нет релиза, мажорная версия 0. Как только пакет стабилизировался, версия 1.0.0.

Начать разработку можно с версии 0.1.0, постепенно доведя пакет до релиза.

Если от вашего пакета, зависят пользователи, у него должна быть версия не ниже 1.0.0.

Патч версия

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

Минорная версия

Минорную версию увеличивают, если добавлена новая функция не нарушающая обратную совместимость.

Так же, если функционал объявлен как deprecated, версию нужно увеличить.

Патч версия, при увеличении минорной должна быть обнулена.

Версия не в релизе

Могут быть “нерелизные” версии, они самые не приоритетные.

1
2
3
1.0.0-test
2.0.1-build123234
2.0.3-build123234+5678

Приоритет

Приоритет версии складывается от большего числа к меньшему. То есть 1.10 < 2.0.1 и 0.1.1 > 0.1.0

Я сделал что-то не так

Если был выпущен релиз с обратно несовместимыми изменениями, нужно выпустить новую минорную версию, которая исправит проблему.

Для чего это все нужно

Если это пакет, которым пользуются люди, то стоит использовать версионирование.

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

Например, если мы правим баги постоянно, будет меняться только последняя цифра.

Авторский пост защищен лицензией CC BY 4.0 .

Хотите оптимизировать свой бизнес, нужен сервис, сайт или интеграция.

Бесплатно расчитаю время разработки, предложу решение вашей задачи.