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

Наиболее распространённый в настоящее время способ нумерации версий

Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными — от исправления ошибки до полного переписывания. В большинстве случаев название программы остаётся тем же, изменяется подназвание — так называемая версия.

Версия программы может быть целым числом (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]]

or

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].

Экзотические схемы

Дональд Кнут нумерует версии системы компьютерной вёрстки ΤΕΧ последовательными приближениями числа $\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 уже практически нигде не использовался. Эмулятор игровых автоматов MAME никогда не дойдёт до версии 1.0, поскольку история игровых автоматов продолжается и поныне.

Маркетинг и суеверия

Коммерческому ПО, чтобы название лучше смотрелось, приходится подключать маркетологов. Например, в странах Азии распространена тетрафобия, поэтому в номерах версий избегают цифры 4. В Европе число 13 считается несчастливым, его или пропускают, или заменяют на X3.

Если история программы очень длинна, её иногда приходится сбрасывать: Adobe Photoshop 7.0 < 8.0 < CS < CS2.

Одной из причин того, что не было Winamp 4, стал каламбур: Winamp 4 skin и англ. 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.

Алгоритмы определения старшинства версий

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

Поскольку чрезмерно сложные алгоритмы чреваты ошибками^[4], а модульные тесты писать не всегда есть время, часто обходятся упрощёнными вариантами: например, строят с помощью битовых полей длинное число (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^[5].

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

Применение схем нумерации ПО в других сферах культуры

• Dungeons & Dragons 3.5
• Крепкий орешек 4.0
• Evangelion 2.0
• Трон 2.0
• Веб 2.0

Примечания

1. ↑ Вопросы и ответы по развертыванию Windows 7
2. ↑ FAQ - Winamp Help
3. ↑ Структура NOTIFYICONDATA на MSDN
4. ↑ Разбор функции CheckWin32Version на Embarcadero Quality Central
5. ↑ Некорректные проверки номеров версий
6. ↑ Andreas Bovens Changes in Opera’s user agent string format  (англ.) (27 May 2009). — Описание мотивов изменений в формате AserAgent-а. Архивировано из первоисточника 22 февраля 2012. Проверено 18 июня 2011.
7. ↑ Например: Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.11