Привет мир!

Сегодня поговорим о версионировании и его важности в разработке. ? Многие из нас используют библиотеки, фреймворки и пакеты — и одним из популярных способов отслеживания их изменений является семантическое версионирование, или SemVer! ?

?  Почему это важно?

Версии продуктов, которые мы делаем или используем, сигнализируют о состоянии изменений. Если обновление было в 2013 году, скорее всего, продукт больше не поддерживается. ?Но даже если продукт обновляется каждую неделю, важно быть осторожным — ведь обновление может нести "breaking changes" и нарушить работу приложения ?, что вызовет у ваших клиентов грустное лицо.

✨ Как SemVer решает проблему с «breaking changes»?

SemVer следует строго определенной структуре, которая делится на три основных части: major, minor, patch, и опциональные, дополнительные маркеры - pre-release и build.
Каждая часть представляет из себя число, и затем они соединяются через точку.

?️  Как это работает?

• Major - номер версии увеличивается, когда в продукте происходят изменения, вносящие "breaking changes" в API. Клиенты должны быть готовы к возможным проблемам с обратной совместимостью. Особенность обновления версии, при поднятии major, minor and patch устанавливаются в 0.
  Пример: было 1.2.5 - стало 2.0.0.

• Minor - увеличение этого числа означает добавление новой функциональности, сохраняющей обратную совместимость.
  Особенность обновления версии, при поднятии minor, patch устанавливаются в 0.
  Пример: было 1.2.5 - стало 1.3.0.

• Patch - при увеличении этого числа сохраняется обратная совместимость, а изменения касаются исправлений багов.

• Pre-Release - после patch версии может быть установлен маркер через дефис, разделенный точкой. Маркер указывает что эта версия является нестабильной. Поэтому при выборе версии они должна иметь приоритет ниже, чем нормальная версия 1.0.0.
  Пример: 1.0.0-alpha.1 - говорит нам о том, что данная версия является пре-релизной по отношении к пакету с версией 1.0.0, и добавился маркер alpha.1.

• Build - означает номер сборки, указывается после patch или pre-Release с добавлением знака +.
  Пример: 1.0.0+001 - это просто номер сборки, при выборе версии имеет тот же приоритет что и просто 1.0.0.

? Полезные советы:

1. Если начинаете свой проект, начинайте с 0.1.0, а не с 1.0.0. Потому что SemVer предполагает, версия не имеет устоявшегося Public API и может измениться в любой момент.

2. Ведите Changelog, когда пишите свой продукт, вашим пользователям будет проще отслеживать изменения, если вы их опишите. Ну или читайте Changelog ****в зависимостях которые используете.
   Пример: changeLog

3. Cоздавайте теги для ваших релизов.
   Пример:  Node

? Другие схемы версионирования:

• CalVer (Calendar Versioning) — это схема версионирования, основанная на дате выпуска программы. Примеры таких проектов включают Pip — менеджер пакетов Python, и операционную систему Ubuntu.

• Схема версионирования Python - она состоит из пяти сегментов: эпоха, выпуск (release), предварительный выпуск (pre-release), пост-выпуск (post-release) и развитие (development).

• Именованное версионирование - просто уникальные имена. Один из ярких примеров — Android, который начал свою коллекцию версиями с именами Cupcake, Donut и Eclair.

• Схема версионирования Spring Project - это схема, распространенная в проектах, связанных с Spring Framework и - Spring Boot. Она расширяет стандарт SemVer, добавляя дополнительные обозначения, такие как RC (release candidates — кандидаты на релиз) и BUILD-SNAPSHOT (для промежуточных или тестовых сборок).

⚠️ Важно: Не все правильно используют SemVer, так что будьте осторожны с малоизвестными пакетами.