Нумерація версій програмного забезпечення

Життєвий цикл успішної комп'ютерної програми може бути дуже довгим; зміни в програмі бувають різними — від виправлення помилки до повного переписування. У більшості випадків назва програми залишається такою ж, змінюється підназва — так звана версія.

Версія програми може бути цілим числом (Corel Draw 11), дробовим числом (Windows 3.11), послідовністю чисел (JDK 1.0.3), роком (Windows 2000) або текстом (Embarcadero Delphi XE). В будь-якому випадку, система версіонування вибирається за декількома критеріями:

• Підтримка тієї чи іншої системи з боку програмного забезпечення для розробки (компілятора, системи контролю версій і т. д.)
• Частота виходу нових версій та їх «сирість». Складна програма, яка випускається раз в декілька років і перед випуском проходить всеохопне тестування, може іменуватися як «Microsoft Word 97 SP2», в той час як в програмі з частими малостабільними випусками доводиться вводити складнішу нумерацію.
• Ступінь сумісності мережних протоколів, документів або доповнень сторонніх розробників — наприклад, «старша» версія збільшується з кожною зміною ABI або API.
• Маркетингові міркування.

Схеми нумерації[ред. | ред. код]

Цифрова нумерація[ред. | ред. код]

У деяких схемах послідовні ідентифікатори використовуються для визначення значимості змін між стадіями розробки: ці зміни класифікуються за рівнями значимості. Рішення про те, яку з послідовностей (в складній нумерації версій) змінити між стадіями розробки, базується на значимості змін на останній стадії розробки, наприклад, в схемі, з версією, яка складається з послідовності 4 чисел, перше число може бути збільшеним тільки тоді, коли код повністю переписаний, в той час як четверте число змінюється при незначних змінах в інтерфейсі або документації. Ця практика дозволяє користувачам (або потенційним наступникам), оцінити, наскільки було протестовано в реальних умовах дане програмне забезпечення. Якщо зміни зроблені, наприклад, між 1.3rc4 (RC — release candidate, реліз-кандидат) і продукційним випуском 1.3, то випуск 1.3rc4 не передбачає рівень тестування виробничого класу і, насправді, містить зміни, які не обов'язково були випробувані в реальних умовах. Такий підхід як правило допускає застосування третього рівня нумерації («зміни»). Наприклад: 1.3.1, 1.3.2, 1.3.3, 1.3.4,… 1.4.1 і т. д.

В пізніших релізах, головне число (major) збільшується, коли відбуваються значні переходи у функціональності, другорядне число (minor) збільшується тільки тоді, коли були додані незначні функції або внесені виправлення. Номер версії змінюється, якщо виправлені всі дрібні недоліки. Для типового програмного продукту використовуються наступні номери: 0.9 (для бета-версії), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, і т. д. Розробники інколи перестрибують, наприклад від версії 5.0 одразу до 5.5, для того щоб позначити додані декілька значних функцій в програмі, однак їх недостатньо, щоб змінити головний номер версії. Деякі розробники^[хто?] вважають, що такі стрибки недоречні.

Інший підхід у використанні головних та другорядних номерів версій полягає в додаванні буквено-цифрової послідовності, визначаючи тим самим стадію розробки релізу: «альфа», «бета», «Реліз-кандидат». Серія версій з використанням цього підходу може виглядати наступним чином: якщо до версій 0.5, 0.6, 0.7, 0.8, 0.9 додаються нові функції їх можна назвати — 1.0b1, 1.0b2, ще плюс нові функції — 1.0b3, потім версія стає 1.0rc1. Якщо версія 1.0rc1 достатньо стабільна, то вона стає 1.0, однак якщо в 1.0rc1 виявляються помилки, які необхідно виправити, вона буде мати номер 1.0rc2 і т. д. Важливою характеристикою цього підходу є дотримання ідентичності стадій розробки версій. Не можна вносити ніяких змін між останньою бета-версією та першим реліз-кандидатом або останнім реліз-кандидатом і готовим продуктом. Якщо це було зроблено, необхідно випустити іншу версію на нижчій стадії розробки.

Іноді наявність людського фактору у створенні номерів версій призводить до помилок в зміні версій. Наприклад, розробники можуть змінити послідовність між версіями, навіть якщо жоден рядок коду не був переписаний, лише для того щоб створити хибне враження, що були внесені значні зміни.

Інші схеми передають значення на окремих послідовностях:

major.minor[.build[.revision]]

або

major.minor[.maintenance[.build]]

Знову ж таки, в цих випадках відмінності «суттєвих» від «незначних» змін, даються довільно і на розсуд автора, як те, що означає «build» або як «revision» відрізняється від «minor change». Аналогічні проблеми відносної значимості змін і номенклатури версій існують у сфері книговидавництва, де номер видання або назва може бути вибрана на основі різних критеріїв.

В більшості пропрієтарного програмного забезпечення, перша офіційна версія програмного продукту має версію 1.

Послідовні номери[ред. | ред. код]

Спочатку програми нумерувалися числами 1, 2, 3 і т. д. — аналогічно до видань книг. Також послідовні номери можуть базуватися на якомусь технічному лічильнику (наприклад, номер версії в системі управління версіями).

Однак, цієї нумерації виявилось мало: доводиться розділяти малі та великі зміни. Для цього існує декілька способів нумерації.

Десятковий дріб[ред. | ред. код]

Історично перший спосіб нумерації, який розділює малі та великі зміни.

Номер версії є десятковим дробом в американському форматі (через точку). Наприклад, перша версія отримує номер 1.0, наступна за нею — 1.1, з невеликою зміною — 1.11. Після серйозного дописування виходить версія 1.5, після чого — 2.0. Порівняння версій проводиться за правилами для десяткових дробів: 1.01 < 1.1 = 1.10 < 1.11 < 1.2 = 1.20.

Послідовність чисел[ред. | ред. код]

Цей спосіб прийнятий, наприклад, у Windows API. Версія складається з декількох (як правило, трьох) чисел, розділених точкою. При збільшенні одного з чисел всі інші, які розташовані після нього скидаються до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1, 2.0.0… Числа порівнюються цілком: 1.1.0 < 1.1.2 < 1.10.0 < 1.11.0 < 1.20.0. Останній нуль може опускатися.

Іноді четвертим числом є номер збірки з наскрізною нумерацією. Ця цифра може збільшуватися на одиницю з кожним випуском (1.0.0.1 < 1.0.1.2 < 1.0.2.3 < 1.1.0.4), або братися з якого-небудь технічного лічильника (компіляцій, нічних збірок, версій коду в системі контролю версій — наприклад, 1.5.2.7682).

Буква в ролі молодшої версії[ред. | ред. код]

Іноді замість третього числа застосовується буква. Так, коли в DotA 6.42 знайшли помилку, новій версії дали назву 6.42b. Це означає: гра залишається тією ж, з тим самим розташуванням перешкод і тим самим балансом, але з виправленою помилкою. Подальші виправлення помилок іменуються 6.42c, 6.42d і т. д.

Вказання стадії розробки[ред. | ред. код]

Якщо розробнику доводиться покладатися на позаштатних тестерів, у версії може вказуватися рівень зрілості програми: альфа-версія, бета-версія, реліз-кандидат, кінцевий випуск, виправлення помилок (service release).

Наприклад, 2.0 alpha1 < 2.0 alpha2 < 2.0 beta < 2.0 rc1 < 2.0 < 2.0 sr1.

Існують різні схеми позначення стадій розробки. Наприклад, третє число може означати:

• 0 — альфа
• 1 — бета
• 2 — реліз-кандидат
• 3 — публічний реліз

Наприклад:

• 1.2.0.1 замість 1.2-a
• 1.2.1.2 замість 1.2-b2 (бета з декількома виправленими помилками)
• 1.2.2.3 замість 1.2-rc3 (реліз-кандидат)
• 1.2.3.0 замість 1.2-r (для комерційного поширення)
• 1.2.3.5 замість 1.2-r5 (для комерційного поширення з багатьма виправленими помилками)

Між серіями 1.0 і 2.6.x ядро Linux використовувало непарні номери для бета-версій, і парні — для стабільних. Наприклад, Linux 2.3 був серією в розробці, а Linux 2.4 — серією стабільних релізів, в яку переріс Linux 2.3. В номері релізу Linux kernel спочатку писався номер другорядної версії, а потім номер релізу в зростаючому порядку. Наприклад Linux 2.4.0 → Linux 2.4.22. Після релізу 2.6 в 2004 році Linux більше не використовує цю систему, тепер цикл релізу набагато коротший. Зараз вони просто збільшують третє число, використовуючи при необхідності четверте.

Така сама система «парне-непарне» використовується деякими іншими продуктами з довгим циклом розробки, такими як GNOME.

Інші схеми нумерації[ред. | ред. код]

Алфавітно-цифрова назва[ред. | ред. код]

Найчастіше застосовується програмне забезпечення з довгою історією і версіями, які виходять рідко. Наприклад: Adobe Photoshop CS2, Windows Vista.

Іноді як додаток до звичайної версії використовується алфавітно-цифрова підназва: Ubuntu 9.04 Jaunty Jackalope.

Дата[ред. | ред. код]

Рік випуску застосовується найчастіше в програмному забезпеченні, версії якого виходять рідко, наприклад: Windows Server 2003.

Розробники проекту Wine також спочатку використовували дати при нумерації версій, вони вказували рік, місяць і день релізу: «Wine 20040505». Зараз Wine використовує «стандартну» нумерацію релізів, остання версія 2010 року має номер 1.2. Компанія Ubuntu Linux використовує схожу схему нумерації, наприклад реліз жовтня 2010 року пронумерований як Ubuntu 10.10. Слід відмітити, що при використанні дат в нумерації версій необхідно використовувати схему ISO, тобто спочатку вказується рік, потім місяць, а потім день (YYYY-MM-DD), причому дефіс можна опускати.

Внутрішні версії[ред. | ред. код]

Часто програма має як торгову назву, так і внутрішню версію, утворену за всіма правилами. Наприклад, Java SE 5.0 має внутрішню версію 1.5.0, Windows 7 — версію 6.1^[1].

Екзотичні схеми[ред. | ред. код]

Дональд Кнут нумерує версії системи комп'ютерної верстки ΤΕΧ послідовними наближеннями числа числа ${\displaystyle \pi ~}$: 3.0 < 3.1 < 3.14 і т. д. Номер останнього стабільного релізу — 3.141592653. Версії іншої програми Дональда Кнута мови METAFONT нумеруються наближеннями до числа e. Зокрема, версія за березень 2008 року мала номер 2.718281.

SuSE Linux почав відлік версій з 4.2, як посилання на відому книгу Дугласа Адамса.

Значення номерів версій[ред. | ред. код]

Версія 1.0 як ключовий етап розробки[ред. | ред. код]

Комерційні програми, як правило, починають нумерувати свої версії з 1.0. Вважається навіть, що версія 1.0 виключно сира і тому потрібно як можна швидше дійти до 1.2 або навіть до 2.0.

В безкоштовних і вільних програмах 1.0 вважається моментом, коли програма визнана готовою до широкого застосування неспеціалістами. При цьому початкові версії програми нумеруються як 0.1, 0.2 і т. д. FreeDOS прийшов до версії 1.0 в 2006 році — коли DOS уже практично ніде не використовувався.

Маркетинг та забобони[ред. | ред. код]

Комерційному програмному забезпеченню, щоб назва краще виглядала, доводиться підключати маркетологів. Наприклад, в країнах Азії поширена тетрафобія, тому в номерах версій уникають цифри 4. В Європі число 13 вважається нещасливим, його або пропускають, або заміняють на X3.

Якщо історія програми дуже довга, її інколи доводиться скидати: Adobe Photoshop 7.0 < 8.0 < CS < CS2.

Однією з причин того, що не було Winamp 4, став каламбур: Winamp 4 skin^[ru] і англ. foreskin — «крайня плоть»^[2].

Пропуски у версіях[ред. | ред. код]

Іноді розробник пропускає номер версії, щоб не відставати від конкурентів або інших продуктів тієї ж компанії: наприклад, Microsoft Access перестрибнув одразу від 2.0 до 7.0. Netscape Communicator пропустив п'яту версію, оскільки Internet Explorer добрався вже до 6.0; до того ж версію 5.0 в User Agent’ах застовпили тестові випуски браузера Mozilla Suite.

В Sun Solaris відкинули першу цифру: 2.8 і 2.9 в маркетингових матеріалах іменувались 8 і 9; Java SE 1.5.0 і 1.6.0 — як Java 5 та 6. Slackware Linux в 1999 році стрибнув від версії 4 одразу до 7.

Microsoft Windows 10 виходить одразу після 8.1.

PHP перестрибує від 5 до 7, причиною оголошено те, що версія 6 виявилась розпіареною, але не могла бути реалізованою, і численні її нововведення були приєднані до 5-ї гілки.^[3]

Алгоритми визначення старшинства версій[ред. | ред. код]

Часто потрібно програмно визначати, яка з двох версій старше — наприклад, «бульбашки» підтримуються у Windows починаючи з 2000^[4], а в ранніх версіях потрібно використовувати інші способи. Така перевірка робиться за доволі складними правилами: наприклад, якщо версія — десятковий дріб, спочатку потрібно порівняти цілі частини як числа; якщо вони рівні, то дробові — як рядки. Якщо версія — трійка або четвірка чисел, то порівнюють числа по одному, доки не буде зафіксовано нерівності.

Оскільки надмірно складні алгоритми можуть призвести до помилок^[5], а модульні тести писати не завжди є час, часто використовують спрощені варіанти: наприклад, будують з допомогою бітових полів^[ru] довге число (1.2.3.4 → 01020304₁₆); або порівнюють версії як рядки в лексикографічному порядку. Перше не спрацює, якщо одне з чисел вийде за межі 256 (1.0.257 < 1.1.0, але 010101₁₆ > 010100₁₆), друге — якщо вийде версія 10 (9.5 < 10.0, але «9.5» > «10.0»).

Іноді подібні спрощення зіграють злий жарт: в перші роки популярності Windows виявилося, що численні програми некоректно перевіряли версію ОС, відмовляючись працювати під 4.0. Тому Windows 95 і Windows 98 мали внутрішні версії 3.95 і 3.98^[6].

Схожі хитрощі застосовувались в User-Agent’і браузера Opera при переході з версії 9.64 на 10.00. Це викликано тим, що деякі сайти, які реагували на User-Agent, або порівнювали номери як рядки (10.0 < 9.5), або брали першу цифру (10.0 = 1.0)^[7]. Розробникам довелося використовувати запис Opera/9.80 замість Opera/10.00, а справжній номер версії додати в кінці UserAgent’а^[8]. Планувалося, що до 11-ї версії UserAgent набуде звичного вигляду, однак обхідний шлях використовувався аж до переходу на рушій Blink (початок 2013 — при тому, що перехід на 10-у версію відбувся ще в 2009 році).

В PHP є спеціальна функція version_compare() для визначення старшинства версій^[9].

Застосування схем нумерації ПЗ в інших сферах[ред. | ред. код]

• Dungeons & Dragons 3.5
• Міцний горішок 4.0
• Evangelion: 2.0
• Tron 2.0
• Веб 2.0
• Версія 1.0^[en]

Посилання[ред. | ред. код]

• Специфікація семантичного версіонування (SemVer)

Див. також[ред. | ред. код]

• Система керування версіями
• Стадії розробки програмного забезпечення
• Ресурси (Windows)

Примітки[ред. | ред. код]