Semver звучит просто: major.minor.patch. Сложность начинается в момент решения — вот это изменение сигнатуры функции, это уже breaking change или ещё нет.
Три числа
- patch — исправление бага без нового поведения
- minor — новая функциональность, обратно совместимая
- major — изменение, ломающее обратную совместимость
Пограничные случаи
| Изменение | Классификация | Почему |
|---|---|---|
| Добавили необязательный параметр | minor | Старый вызов работает без изменений |
| Изменили тип возврата с number на string | major | Код, ожидающий number, сломается |
| Исправили баг в вычислении | patch, но осторожно | Кто-то мог полагаться на старое поведение |
| Удалили deprecated метод | major | Удаление публичного API — всегда breaking |
Пре-релизные версии
Суффикс после дефиса означает нестабильную версию до финального релиза, например 2.1.0-beta.1 или 2.1.0-rc.2. Пакетные менеджеры вроде npm по умолчанию не устанавливают такие версии без явного указания тега, что защищает пользователей от случайного попадания нестабильного релиза в прод.
Как не гадать при тегировании
Если среди коммитов с прошлого релиза есть хотя бы один breaking change — версия major, сколько бы мелких фиксов ни было рядом. Git Tag Version Bumper считает следующую версию по типу изменения автоматически.
Итоговый чеклист
Breaking change почти всегда major, даже если старый код формально не падает с ошибкой, а просто ведёт себя иначе.
Пре-релизные суффиксы защищают пользователей пакета от случайной установки нестабильной версии.
Перед тегом стоит свериться со списком коммитов, а не полагаться на память о том, что там было за последний месяц.