Семантическое версионирование

Семантическое версионирование (semantic versioning) — это схема нумерации версий, которая передаёт смысл изменений в коде при переходе от одной версии к другой. Она помогает разработчикам понять, к чему приведёт обновление библиотеки или приложения.

Семантическое версионирование строится на следующих принципах:

1. Формат номера версии. Используется номер версии из трёх частей в формате MAJOR.MINOR.PATCH. Например, 2.1.7 означает мажорную версию #2, минорную #1 и патч #7.

2. Обратная совместимость. Новая версия MINOR или PATCH должна быть обратно совместимой с предыдущей версией. Это значит, что код, написанный для старой версии, должен работать с новой версией без изменений.

3. Увеличение номера версии. При внесении изменений в библиотеку или приложение номер версии должен увеличиваться в зависимости от типа изменений:

• Мажорная версия (major): увеличивается при внесении несовместимых изменений в API.
• Минорная версия (minor): увеличивается при добавлении функциональности с сохранением обратной совместимости.
• Патч (patch): увеличивается при исправлении ошибок с сохранением обратной совместимости.

Допустим, есть библиотека версии 1.2.3. Если добавить новую функцию обратно совместимым способом, версия увеличится до 1.3.0. Если исправить ошибку обратно совместимым способом, версия станет 1.2.4. А если внести несовместимое изменение в API, из-за которого пользователям придётся менять свой код, версия увеличится до 2.0.0.

Концепция семантического версионирования встроена в современные пакетные менеджеры, такие как npm, pip, composer и другие. При добавлении сторонней библиотеки в проект можно указать диапазон версий, чтобы получать последние исправления ошибок и новые функции, не рискуя сломать код из-за несовместимых изменений. Например, если указать диапазон ^1.2.3, будет установлена любая версия 1.x.x с патчем не ниже 3. Это позволяет автоматически получать новые патчи и минорные обновления без ломающих изменений.

Другие виды номеров версий и меток

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

• Номер сборки (build number): сборка (build) — это процесс преобразования исходного кода в исполняемую программу или библиотеку. Компиляция кода, запуск тестов и упаковка результата в формат для распространения — всё это часть процесса сборки. Чем сложнее программа, тем больше шагов в этом процессе. Для чего-то вроде операционной системы сборка может занимать часы или даже дни. Сама инфраструктура сборки может быть довольно сложной и иногда вызывает ошибки в конечном продукте, поэтому важно сохранять историю сборок и уметь их воспроизводить. Вот почему в сложных проектах каждой сборке присваивается уникальный номер. Номера сборок обычно идут по порядку и могут использоваться для идентификации конкретной сборки программы. Например, 1.0.0-build123 означает 123-ю сборку версии 1.0.0. Номера сборок обычно используются разработчиками внутри команды и не показываются обычным пользователям, но в некоторых программах их всё равно можно увидеть.

• Ночная сборка (nightly): версии, которые автоматически собираются каждую ночь из последнего кода в репозитории (например, 1.0.0-nightly.20220315). Ночные сборки обычно сопровождаются датой или номером сборки. Эти версии чаще всего используются разработчиками для тестирования самых новых функций и исправлений, а также для сообщения об ошибках команде разработки.

• Альфа (alpha): версии, которые всё ещё находятся в активной разработке и не отличаются стабильностью (например, 1.0.0-alpha.35). Они обычно выпускаются, чтобы получить ранние отзывы от пользователей. Любая ночная сборка может стать альфа-версией, если она считается достаточно стабильной для тестирования.

• Бета (beta): версии, которые более-менее завершены и стабильны, но всё ещё не считаются готовыми к продакшену (например, 1.0.0-beta.1). Такие версии обычно выпускаются для выбранной группы пользователей (так называемых бета-тестеров), чаще всего добровольцев или сотрудников, чтобы протестировать программу в реальных условиях и отловить оставшиеся ошибки.

• Кандидат в релиз (release candidate, RC): версии, которые считаются стабильными и готовыми к продакшену, но всё ещё требуют тестирования на более широкой аудитории (например, 1.0.0-rc.1). Такие версии обычно выпускаются публично, чтобы собрать отзывы от большой группы пользователей. Если серьёзных проблем не найдено, версия RC становится финальным релизом.

• Стабильная версия (stable): версии, которые считаются стабильными и готовыми к продакшену (например, 1.0.0). Эти версии выпускаются для широкой публики и рекомендуются для обычного использования.

• LTS (long-term support): версии, которые поддерживаются в течение длительного времени (например, 1.0.0-lts). Обычно такие версии поддерживаются несколько лет, получая обновления безопасности и исправления ошибок. Конечно, не каждой программе нужны LTS-версии. Чаще всего они встречаются в крупном софте, таком как библиотеки, фреймворки или операционные системы, которые массово используются в продакшен-среде. Тем, кто использует такой софт в продакшене, нужно быть уверенными, что на него можно положиться в долгосрочной перспективе, и что он будет получать важные обновления.