Життєвий цикл успішного програмного продукту може розтягнутися на роки, і за цей час він проходить через багато трансформацій — від дрібних виправлень до повної перебудови архітектури. Щоб користувачі та розробники розуміли, у якому стані перебуває система перед ними, зберігши при цьому узнавану назву, застосовують версіонування. Версія — це «підназва», яка фіксує певний етап розвитку ПО.
Суть і значення нумерації версій
Нумерація версій — це впорядкована система присвоєння унікальних ідентифікаторів різним станам продукту. Зазвичай це послідовність чисел або літер, що зростає зі зростанням розвитку проекту. Головне завдання версіонування — дати зрозуміле засіб відстеження змін, щоб користувачі могли порівнювати свої копії з новими випусками, а розробники — керувати кодом і залежностями.
Вибір конкретної схеми залежить від кількох факторів: від інструментів розробки та систем контролю версій, від частоти релізів та бажаної ступені деталізації. Важкі, рідкі релізи зазвичай витримують просту схему, тоді як часто оновлювані продукти вимагають більш точного нумерування. Також важливі сумісність протоколів, форматів та розширень, потреба в машиночитанні для управління залежностями та маркетингові міркування.
Розповсюджені схеми нумерації
Єдиного стандарту немає, тож проєкти обирають підхід, який найкраще відповідає їхнім цілям та практикам.
Послідовні номери
Ранні програми часто отримували прості цілі номери — 1, 2, 3 — за аналогією з виданнями книжок. Цей спосіб усе ще застосовний до рідкісних стабільних релізів, наприклад окремих операційних систем або графічних редакторів. Дрібні сервісні правки в таких продуктах зазвичай не відображаються у видимому номері версії.
Десяткова крапка
Формат у вигляді десяткової крапки розділяє незначні та значні зміни: 1.0 — перший випуск, 1.1 — незначне оновлення, 2.0 — значне розширення функціональності. Іноді розробники стрибають, наприклад, з 2.0 на 2.5, щоб підкреслити набір важливих, але не радикальних нововведень. Для попередніх випусків використовують номери менші за одиницю: 0.1, 0.9 тощо.
Послідовність чисел (Major.Minor.Patch)
У цій схемі зазвичай виокремлюють три рівні версії:
- major — глобальні зміни, які можуть ламати зворотну сумісність;
- minor — додавання функціоналу з збереженням сумісності;
- patch — виправлення помилок без зміни API.
При збільшенні одного з чисел наступні зазвичай скидаються до нуля. Наприклад, після 1.0.2 слідує 1.1.0. Іноді додають четвертий елемент — номер збірки, який зростає з кожною компіляцією або береться з системи контролю версій.
Літера як молодша версія
Іноді замість третього числа використовують літери: 6.42 → 6.42b → 6.42c. Це показує, що функціональність залишилася незмінною, але внесені окремі правки.
Позначення стадії розробки
При активній розробці прийнято позначати рівень зрілості випуску:
- альфа-версія — рання внутрішня збірка;
- бета-версія — доступна для зовнішнього тестування;
- реліз-кандидат — потенційно готова до релізу версія;
- кінцевий випуск — готовий до широкого поширення релізу.
Послідовність може виглядати так: 2.0 alpha1 < 2.0 beta < 2.0 rc1 < 2.0. У окремих схемах нуль у першому або третьому числі слугує маркером бета-версії або внутрішнього релізу.
Алфавітно-цифрова назва та дата
Довгоживучі продукти іноді використовують літерно-цифрові назви (наприклад, Adobe Photoshop CS, CC) або рік випуску (Microsoft Office 2014). Формат ГГГГ-ММ-ДД упрощає порівняння релізів за старшиною.
Внутрішні версії
У багатьох проектах є маркетингова назва та окрема технічна версія, підпорядкована суворим правилам. Наприклад, Java SE 5.0 відповідає внутрішній версії 1.5.0. Такі номери допомагають швидко зв’язатися з розробниками при розборі помилок.
Екзотичні схеми
Іноді зустрічаються індивідуальні підходи. Так, Дональд Кнут нумерує версії системи типографіки ΤΕΧ числами, наближеними до π: 3.0, 3.1, 3.14 тощо, що підкреслює поступове вдосконалення.
Значення номера 1.0 та маркетингові аспекти
Номер 1.0 часто вважають віхою: для комерційних продуктів це перший публічний реліз, хоч іноді його вважають ще «сирим» і очікують швидкого переходу до 1.2 або 2.0. У світі вільного ПЗ версія 1.0 сигналізує про готовність програми до широкого використання непрофесіоналами.
Маркетинг часто впливає на нумерацію: номери можуть змінюватися, щоб створити відчуття значного оновлення, або пропускати версії, щоб урівнятися з конкурентами. Також існують забобони — наприклад, число 13 іноді обходять чи замінюють на «X3».
Алгоритми визначення старшинства версій
Часто потрібно автоматично визначити, яка з двох версій новіша — це критично для оновлень та перевірки сумісності. У випадку десяткової дроби порівнюють цілі частини як числа, а дробові — як рядки. Для багатокомпонентних версій порівняння відбувається покомпонентно до першої відмінності.
Прості методи, такі як лексикографічне порівняння рядків, дають помилки: "10.0" може виявитися «меншим» за "9.5". Через подібні проблеми операційні системи іноді використовують маскувальні внутрішні номери, щоб старі програми коректно визначали сумісність. У мовах програмування є спеціалізовані функції, наприклад version_compare() у PHP, які вирішують ці задачі правильно.
Версіонування поза програмним забезпеченням
Ідеї версіонування вийшли за рамки програмування: їх застосовують у настільних рольових іграх (Dungeons & Dragons 3.5), у кінематографі («Evangelion 2.0») та в термінах на кшталт «Веб 2.0» і «Веб 3.0», де числова нумерація відображає зміну парадигм.
