У цій статті
Що таке семантичне версіонування?
Семантичне версіонування (SemVer) — схема версіонування, яка надає значення кожній частині номера версії. Створений Томом Престоном-Вернером, SemVer надає універсальну угоду для комунікації природи та впливу змін програмного забезпечення лише через номери версій.
Дотримуючись SemVer, розробники та користувачі можуть миттєво зрозуміти, чи вносить оновлення несумісні зміни, нові функції або виправлення помилок — просто прочитавши номер версії. Ця передбачуваність є критично важливою для управління залежностями в сучасних програмних екосистемах.
Формат SemVer
Семантична версія складається з трьох числових компонентів, розділених крапками: MAJOR.MINOR.PATCH.
- MAJOR — збільшується при внесенні несумісних змін API. Перехід з 1.x.x на 2.0.0 сигналізує про те, що існуючий код може перестати працювати
- MINOR — збільшується при додаванні функціональності зворотньо-сумісним способом. Перехід з 1.2.x на 1.3.0 означає нові функції без порушення існуючих
- PATCH — збільшується при зворотньо-сумісних виправленнях помилок. Перехід з 1.2.3 на 1.2.4 означає, що були виправлені лише помилки
- Кожен компонент повинен бути невід'ємним цілим числом і не повинен містити початкові нулі (1.02.3 є невалідним)
Спробуйте безкоштовно — реєстрація не потрібна
Перевірити версію SemVer →Діапазони версій
Менеджери пакетів використовують діапазони версій для вказання сумісних версій залежностей. Розуміння цих діапазонів є необхідним для надійних збірок.
- Діапазони з карет (^1.2.3) — дозволяють зміни, які не змінюють найлівішу ненульову цифру. ^1.2.3 означає будь-яку версію від 1.2.3 до, але не включаючи 2.0.0
- Діапазони з тильдою (~1.2.3) — дозволяють лише зміни рівня патча. ~1.2.3 означає будь-яку версію від 1.2.3 до, але не включаючи 1.3.0
- Точна версія (1.2.3) — прийнятна лише ця конкретна версія, без гнучкості
Випадки використання
Семантичне версіонування є основою сучасного управління пакетами та робочих процесів випуску.
- npm, pip та Cargo — менеджери пакетів покладаються на SemVer для вирішення дерев залежностей та запобігання потраплянню несумісних змін у виробниче середовище
- CI/CD-конвеєри — автоматизовані системи використовують теги SemVer для запуску збірок, публікації випусків та генерації журналів змін
- Версіонування API — REST API використовують мажорні версії в URL (v1, v2) для підтримки зворотньої сумісності під час розвитку
- Автори бібліотек — публікація бібліотеки з правильним SemVer сигналізує споживачам, коли оновлення безпечні
Передреліз та метадані
SemVer підтримує два необов'язкових розширення, які додають контекст до номерів версій без впливу на правила пріоритетності.
- Ідентифікатори передвипуску — додаються після дефісу: 1.0.0-alpha, 1.0.0-beta.2, 1.0.0-rc.1. Вони вказують на версії, що ще не є стабільними та мають нижчий пріоритет, ніж відповідний випуск
- Метадані збірки — додаються після знака плюс: 1.0.0+build.123, 1.0.0-beta+exp.sha.5114f85. Метадані збірки ігноруються при визначенні пріоритетності версій
- Версії передвипуску сортуються за допомогою ідентифікаторів, розділених крапками: числові ідентифікатори сортуються числово, буквено-цифрові — лексично
FAQ
Чи обробляється 0.x.x інакше, ніж 1.x.x?
Так. У SemVer версія 0.x.x вказує на початковий розробку, де будь-що може змінитися в будь-який час. Публічний API не слід вважати стабільним. Після випуску 1.0.0 ви зобов'язуєтеся дотримуватися правил SemVer для всіх наступних випусків.
Чи можна використовувати v як префікс (v1.2.3)?
Специфікація SemVer не включає префікс v — канонічний формат є 1.2.3. Однак багато інструментів (теги Git, випуски GitHub) за угодою використовують v1.2.3. Більшість валідаторів приймають обидві форми.
Що станеться, якщо я забуду збільшити мажорну версію для несумісних змін?
Споживачі, які використовують діапазони з карет, автоматично отримають оновлення, і їхні збірки можуть несподівано зламатися. Саме тому дисципліна SemVer є критично важливою — це соціальний контракт між авторами бібліотек та споживачами.