Семантичне версіонування

Семантичне версіонування — це схема нумерації версій, яка передає зміст того, що саме змінилося в коді від версії до версії. Вона допомагає розробникам зрозуміти, чим обернеться оновлення бібліотеки чи застосунку до нової версії.

Семантичне версіонування тримається на таких принципах:

1. Формат номера версії. Використовується номер версії з трьох частин у форматі MAJOR.MINOR.PATCH. Наприклад, 2.1.7 означає мажорну версію №2, мінорну версію №1 і патч №7.

2. Зворотна сумісність. Нова MINOR- або PATCH-версія має бути зворотно сумісною з попередньою. Тобто код, написаний для старішої версії, має працювати з новою без змін.

3. Збільшення номера версії. Коли до бібліотеки чи застосунку вносяться зміни, номер версії збільшується залежно від типу зміни:

• Мажорна версія: збільшується, коли з'являються несумісні зміни API.
• Мінорна версія: збільшується, коли додається нова функціональність без порушення зворотної сумісності.
• Патч-версія: збільшується, коли виправляються помилки без порушення зворотної сумісності.

Скажімо, у тебе є бібліотека версії 1.2.3. Якщо зміна додає нову функціональність і не ламає зворотну сумісність, версія стане 1.3.0. Якщо зміна виправляє помилку без порушення сумісності — 1.2.4. А якщо зміна вносить несумісну зміну API, через яку користувачам бібліотеки доведеться щось міняти у своєму коді, версія стане 2.0.0.

Концепція семантичного версіонування вбудована в сучасні менеджери пакетів, як-от npm, pip, composer та інші. Коли ти додаєш сторонню бібліотеку до проєкту, можна вказати діапазон версій, щоб отримувати найновіші виправлення й можливості без ризику зламати код через несумісні зміни. Наприклад, якщо вказати діапазон ^1.2.3, ти отримаєш будь-яку версію 1.x.x із патч-версією щонайменше 3. Так найновіші патчі й мінорні версії підтягуються автоматично, без несумісних змін.

Інші види номерів версій і позначок

Окрім числових версій, у світі програмного забезпечення трапляються й інші типи версій, номерів і позначок:

• Номер збірки: збірка (build) — це процес перетворення вихідного коду на виконувану програму чи бібліотеку. Компіляція коду, запуск тестів і пакування результату у формат для розповсюдження: усе це частини процесу збірки. Що складніше програмне забезпечення, то більше кроків у цьому процесі. Для чогось на кшталт операційної системи збірка може тривати години або навіть дні. Сама інфраструктура збірки буває доволі складною й може спричиняти помилки в кінцевому продукті, тому важливо мати історію збірок і вміти їх відтворювати. Саме тому у складних програмних проєктах кожній збірці присвоюється унікальний номер. Номери збірок зазвичай послідовні, і за ними можна ідентифікувати конкретну збірку. Наприклад, 1.0.0-build123 означає 123-тю збірку версії 1.0.0. Номери збірок здебільшого використовуються всередині команд розробки й не показуються кінцевим користувачам, хоча в деяких програмах їх усе ж видно.

• Nightly: версії, які збираються автоматично щоночі з найсвіжішого коду в репозиторії (наприклад, 1.0.0-nightly.20220315). Nightly-версії зазвичай супроводжуються датою або номером збірки. Такими версіями переважно користуються розробники, щоб тестувати найновіші можливості й виправлення та повідомляти команду розробки про проблеми.

• Alpha: версії, які ще в активній розробці й поки нестабільні (наприклад, 1.0.0-alpha.35). Їх зазвичай випускають, щоб отримати ранні відгуки користувачів. Будь-яка nightly-збірка може стати alpha-версією, якщо вона достатньо стабільна для тестування.

• Beta: версії, які більш-менш завершені та стабільні, але ще не вважаються готовими до повноцінного використання (наприклад, 1.0.0-beta.1). Такі версії зазвичай випускають для обраної групи користувачів (так званих бета-тестерів, здебільшого волонтерів або співробітників), щоб випробувати програму в реальних умовах і виловити решту помилок.

• Release Candidate (RC): версії, які вважаються стабільними й готовими до релізу, але їх ще має випробувати ширша аудиторія (наприклад, 1.0.0-rc.1). Такі версії зазвичай випускають публічно, щоб зібрати відгуки більшої групи користувачів. Якщо серйозних проблем не знайдено, RC-версія стає фінальним релізом.

• Stable: версії, які вважаються стабільними й готовими до використання (наприклад, 1.0.0). Вони випускаються публічно й рекомендовані для загального користування.

• LTS (Long-Term Support): версії з подовженою підтримкою (наприклад, 1.0.0-lts). Такі версії зазвичай супроводжуються кілька років і отримують оновлення безпеки та виправлення помилок. Звісно, LTS-версії потрібні не всякому програмному забезпеченню. Вони типові для великих продуктів — бібліотек, фреймворків чи операційних систем, які масово використовуються в робочих середовищах. Тим, хто використовує таке програмне забезпечення в реальних проєктах, важлива впевненість, що на нього можна покладатися довгий час і що воно отримуватиме оновлення безпеки та виправлення помилок.