Семантическое версионирование (SemVer) и номера версий

Коротко: SemVer нумерует версии как MAJOR.MINOR.PATCH: major — для несовместимых изменений, minor — для новых совместимых функций, patch — для исправления ошибок.

Подробнее: Номер версии должен задавать ожидания: могу ли я безопасно обновиться? Semantic Versioning 2.0 (semver.org) даёт для этого чёткие правила.

Подробности

Схема

MAJOR.MINOR.PATCH, например 2.4.1:

• PATCH (2.4.1 → 2.4.2): обратно совместимые исправления.
• MINOR (2.4.2 → 2.5.0): новые функции, обратно совместимые; patch сбрасывается в 0.
• MAJOR (2.5.0 → 3.0.0): несовместимые изменения (breaking changes); minor/patch сбрасываются в 0.

Предварительные версии: 3.0.0-beta.1, -rc.2; метаданные сборки: 1.0.0+20260101. 0.y.z считается нестабильной: сломаться может что угодно. Первая стабильная версия — 1.0.0.

Диапазоны версий (npm, Python и др.)

• ^1.4.2 (npm): совместимо, допускает 1.x.x начиная с 1.4.2 (но не 2.0.0).
• ~1.4.2: только обновления patch (1.4.x).
• 1.4.2: точно.
• >=1.2 <2: диапазон.
• Python: ~=1.4.2 (совместимо), ==, >=.

Плюс lock-файлы, чтобы сборки оставались воспроизводимыми. npm outdated, npm update, Renovate/Dependabot поддерживают зависимости в актуальном состоянии; major-обновления читайте (журнал изменений/руководство по миграции) и спокойно тестируйте.

Когда это breaking change?

Удалённые/переименованные функции или параметры, изменённые возвращаемые значения, иные ошибки/исключения, более строгая валидация, изменённые значения по умолчанию, более высокие минимальные версии (Node, Python), отказ от платформ, изменённые форматы ответов API, изменения схемы базы данных. Всё, на что пользователи могут полагаться, — часть публичного интерфейса. Лучше сначала объявить устаревшим (предупреждение, переходный период), затем удалить в следующем major.

Альтернативы и практика

• CalVer (2026.10, Ubuntu 24.04): на основе времени, подходит для приложений/релизов с определённым ритмом.
• Хэши сборки/коммита для развёртываний.
• Conventional Commits (feat:, fix:, feat!:) позволяют автоматически назначать версии и вести журналы изменений (semantic-release, release-please).
• Теги Git v1.2.3, примечания к релизу с подсказками по миграции.
• Для веб-API: версия в URL/заголовке (см. версионирование API); приложения показывают версию в диалоге «О программе» (поддержка!).
• Будьте последовательны: лучше надёжно применять простую схему, чем сложную, которая часто ломается.

См. также: Теги Git, релизы и журнал изменений, Версионирование API