Семантичне версіонування (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