Как пишется версия программы

Жизненный цикл любой программы — будь то десктопное или веб-приложение может быть продолжительным. Если проект активно развивается то в нем постоянно что-то меняется: добавляются новые функции или исправляются ошибки. Как правило, название проекта при этом никуда не девается, а меняется версия проекта.

Вариант 1. Нумерация целым числом

Обычно программы нумеруются целыми числами 1,2,3,4,5,6,7 и т.д. когда новая версия программы сложна, долго пишется и появляется только раз в год или несколько лет. После того, как такая программа будет протестирована, она помечается целым номером и выпускается для использования. Какие-либо мелкие изменения, добавляемые в процессе обслуживания программы, не учитываются в нумерации. Например, целым числом нумеруется Corel Draw (Corel Draw 10, Corel Draw 11)

Вариант 2. Десятичная дробь

Другой способ, который позволяет указать в версии программы серьезные и не большие изменения — это нумерация десятичной дробью. Например, как правило первая версия программы получает номер 1.0. При небольшом изменении увеличивается вторая цифра — 1.1. А при добавлении новой функции, изменяется вновь первая цифра, а вторая, следующая за ней, обнуляется — 2.0.

Вариант 3. Последовательные числа

Нумерация версий программы последовательными числами выглядит следующим образом.Версия программы состоит из трех или четырех чисел, разделенных точкой: например, 2.7.5.

• Первое число — старшая версия (major), изменяется при кардинальных изменениях программы
• Второе число — младшая версия (minor), изменяется при значительных изменениях функциональности
• Третье число (или буква) — стадия разработки
  • Альфа версия — стадия тестирования приложения, число 0 или символ a
  • Бета версия — стадия публичного тестирования приложения, число 1 или символ b
  • RC (Release candidate) — релиз-кандидат — стадия-кандидат на то, чтобы стать стабильной версией, число 2 или символы rc
  • RTM (Release To Manufacturing) — релиз — стабильная версия приложения, число 3 или символы rtm
  • GA (General availability) — общедоступный релиз

Он может отсутствовать, и тогда вместо него ставится следующее число.

• Четвертое число — небольшие изменения (micro, maintenance), изменяется при любом, даже незначительной правке программы

Когда одно из чисел увеличивается, то все следующие за ним сбрасываются до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0 и т.д. Часто, последний ноль может отбрасываться из версии, например: 1.0.0 = 1.0

Например, последовательные числа используют в Adobe Photoshop (Adobe Photoshop 7.0)

Вариант 4. Нумерация годом

Обычно, год используют в качестве нумерации для программных продуктов, которые долго разрабатываются и новые версии которых выходят не очень часто. Например, продукты того же Microsof, взять хотя бы их операционную систему или пакеты офисных утилит Word, Excel, PowerPoint и т.п.

Вариант 5. Нумерация текстом

Кроме чисел, в нумерации программы могут участвовать и различные буквы. Например, как это сделано в интегрированной среде разработки Delphi (Delphi XE)

Выбор, как именно нумеровать программу, выбирается по следующим причинам:

• в зависимости от использования системы контроля версии или иных инструментов разработки
• частота изменений в программе
• в маркетинговых целях, когда чтобы не отставать от конкурентов, разработчики проекта перескакивают на новый номер версии

Какой именно тип нумерации версий используете вы?

Время на прочтение
10 мин

Количество просмотров 47K

Методология изменения версий продукта программного обеспечения

   Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.

   При имеющейся категории номера версии (главная, второстепенная), номера обычно выставляются в возрастающем порядке и соответствуют новым разработкам в программном обеспечении. На начальном уровне отслеживанием постепенно появляющихся версий электронной информации занимается система управления версиями, позволяющая хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определяя, кто и когда сделал то или иное изменение и многое другое. Вместе с тем для отслеживания изменений программного обеспечения было создано большое количество схем присвоения номеров версиям.

   Каждой стадии разработки программного обеспечения соответствует уникальный идентификатор, который состоит из последовательности номеров или букв. В некоторых схемах последовательные идентификаторы используются для определения значимости перемен между стадиями разработки: эти перемены классифицируются по уровням значимости. Решение о том какую последовательность изменить между стадиями разработки основано на значимости перемен на последней стадии разработки, например в схеме, с версией, состоящей из последовательности 4 чисел, первое число может быть прибавлено только тогда когда код полностью переписан, в то время как четвертое число изменяется при незначительных переменах в интерфейсе или документации.

   В более поздних релизах, главное число (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 и т.д. Важной характеристикой этого подхода является соблюдение идентичности стадий разработки версий. Нельзя вносить никаких изменений между последней бета-версией и первым релиз кандидатом или последним релиз кандидатом и готовым продуктом. Если вы это сделали, необходимо выпустить другую версию на более низкой стадии разработки.

   Известные примеры буквенно-цифровых версий — Macromedia Flash MX, Adobe Photoshop CS2.

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

Обозначение стадии разработки

   Для присвоения альфа или бета статуса релизам, которые еще не достаточно стабильны для практического применения, существуют схемы, где в первой последовательности используется ноль. Он ставится третьим числом в тех случаях, когда планируется еще тестировать версию или версия годна только для внутреннего применения.

Последовательность в таких схемах следующая:

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

Например:

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

Разделение последовательностей

   При публикации последовательности могут быть разделены знаками препинания. Выбор знаков препинания и их использования зависит от схемы.

В следующем перечне показаны возможные примеры разделенных схем на одном и том же релизе:

• Схема может использовать один и тот же знак препинания между последовательностями: 2.4.13, 2/4/13, 2-4-13
• Выбор схемы, какие числа разделять, а какие нет, может быть противоречивым: 2.413
• Схема может использовать разные знаки препинания внутри одной последовательности: 2.4_13

Номера последовательностей

    Иногда в схемах существует четвертое неопубликованное число, которое обозначает сборку (build) программного обеспечения (как это делает ,Microsoft). ,Adobe Flash наоборот больше всего выделяет четвертое число версии: 10.1.53.64. Некоторые компании также включают дату сборки. Номера версий могут включать буквы и знаки препинания: Lotus 1-2-3 Release 1a.

Приращение последовательности

   Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, и т.д. Примером такого продукта может служить MediaWiki. В других программах используются десятичные номера: 1.7, 1.8, 1.81, 1.82, 1.9, и т.д. В таких программах после версии 1.8 будет идти версия 1.81, текущие релизы будут обозначаться 1.81a, 1.81b, и т.д.

Использование дат в версиях

    Разработчики проекта Wine использовали даты при нумерации версий, они указывали год, месяц и день релиза: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию релизов, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например релиз апреля 2010 года пронумерован как Ubuntu 10.04. Номера сборок Microsoft Office тоже на самом деле закодированные даты.

   Здесь следует отметить, что при использовании дат в нумерации версий необходимо использовать схему ISO, то есть сначала указывается год, затем месяц, а потом день (YYYY-MM-DD), причем дефис можно опускать.

   Существуют также примеры нумерации версии годом выпуска (Adobe Illustrator 88, WordPerfect Office 2003). Хотя такой ход чаще всего используется в маркетинговых целях, и настоящий номер версии все равно существует. Например, версия Microsoft Windows 2000 Server на самом деле имеет номер Windows NT 5.0.

Схема нумерации версий TeX

   Система TeX использует уникальную схему нумерации версий. После появления версии номер 3, ко всем последующим обновленным версиям после точки добавляли цифру, соответствующую последовательности числа Π это одна из форм унарной системы счисления – номер версии соответствует номеру цифры в числе Π. Номер последней версии 3.1415926. Такой метод отражает стабильность системы TeX. Разработчик TeX Дональд Кнут сказал, что последняя версия выйдет после его смерти и ее номер будет полное число Π, в которой все оставшиеся недочеты станут постоянными функциями. Подобной схемы придерживается METAFONT, нумеруя версии числами из математической константы e.

Схема Apple

   ,Apple использует формализованную структуру нумерации версий основанную на структуре NumVersion, она состоит из номера главной версии (1-2 числа), номера второстепенной версии (1 число), номера исправленной версии («bug» version) (1 число), индикатора стадии разработки (преальфа, альфа, бета и т.д.) и номера пререлиза (0-255). При написании этих номеров версий в строке, существовало условное соглашение опускать часть номера, обозначающую нулевую или последнюю стадию разработки. На пример: 1.0.2b12, 1.0.2 (вместо 1.0.2f0), и 1.1 (вместо 1.1.0f0).

Другие схемы

   Производители программного обеспечения используют различные схемы для обозначения релиза их софта. Например, операционная система Microsoft Windows появилась на рынке со стандартной числовой схемой обозначения версий (от Windows 1.0 до Windows 3.11). Позднее разработчики Microsoft начали разделять названия версий в маркетинговых целях, то есть, сначала используя год релиза (Windows 95 (4.0), Windows 98 (4.10), Windows 2000 (5.0)), потом буквенно-цифровые коды (Windows Me (4.90), Windows XP (5.1)), после чего названия брендов (Windows Vista (6.0)). Судя по последнему релизу Windows 7, Microsoft снова вернулся к стандартной числовой схеме, хотя официальное название версии Windows 7 это 6.1.

   В проекте Debian для релизов операционной системы используется «major/minor» схема, а для названий программных продуктов при разработке используются имена из мультфильма «История Игрушек».

Скрытые номера версий

   Продукт программного обеспечения может иметь так называемый «скрытый» номер версии, который не указан в основном названии продукта (обычно в составлении скрытого номера соблюдаются все правила нумерации версий). Например, версия Java SE 5.0 имеет внутренний номер 1.5.0, а версии Windows начиная от NT 4, продолжают внутреннюю стандартную нумерацию версий: Windows 2000 это NT 5.0, XP это Windows NT 5.1, 2003 это NT 5.2, Vista это NT 6.0 и 7 это NT 6.1.

Предварительные версии продуктов программного обеспечения

   Вместе с различными схемами обозначения версий, перечисленными выше, система, обозначающая предварительные версии используется в большинстве случаев как программа, прокладывающая себе путь через все стадии разработки программного обеспечения. Программы, находящиеся на ранних стадиях разработки называются «альфа» (первая буква греческого алфавита). Более зрелые программы, но еще не готовые к релизу называются «бета» (вторая буква греческого алфавита). В основном продукты программного обеспечения «альфа» тестируются только разработчиками, в то время как продуты «бета» распространяются на публичное тестирование. Этим двум версиям продукта обычно присваивается номер меньше 1, например 0.9, так как 1.0. это уже для публичного релиза. Однако если создается предварительная версия к уже существующему продукту, то она может быть обозначена буквой «а» (значит альфа) добавленной к номеру версии готового продукта, например версия 2.5 – предварительная версия 2.5.а или 2.5а. Продукты готовые к релизу могут быть обозначены тегом «rc-#», что означает релиз кандидат (release candidate). Когда версия уже выпущена, тег убирается.

Нечетные числа в обозначении версий для разработки релиза

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

Apple и нечетные числа

   У компании Apple были свои особенности на счет нечетных чисел, особенно во время системы MacOS. Даже тогда когда выпускались второстепенные (minor) релизы номер версии редко был больше чем 1, а если номер нужно было увеличить они перескакивали сразу на 5, предлагая при этом небольшое изменение величины между главным и второстепенным релизом (например, 8.5 значит «восемь с половиной», а 8.6 значит «восемь с половиной точка один»). Завершенная последовательность версий выглядит так: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (3.1 пропущена), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.

Версия 1.0 как ключевой этап разработки

   Разработчики проприетарного программного обеспечения всегда называют первый релиз программы версия 1, а затем увеличивают номер главной версии после каждого переписывания кода. Это значит, что программа может достичь версии 3 всего за несколько месяцев разработки, при этом она еще возможно не станет стабильной и надежной.

   В отличие от компаний, сообщество свободного программного обеспечения используют версию 1.0 как ключевой этап разработки, обозначая тем самым, что продукт завершен, в нем есть все необходимые функции, и он достаточно надежен для публичного использования.

   Согласно этой схеме, номер версии медленно приближается к 1.0 пока устраняются все недочеты в подготовке к релизу. Разработчики MAME, например, не стремятся выпускать версию 1.0 программы эмулятора, аргументируя это тем, что она никогда не будет до конца завершена, потому что аркадные игры будут появляться всегда. За версией 0.99 просто следует версия 0.100. Подобный пример Xfire, после релиза 1.99 идет 1.100. Так за 6 лет существования eMule все еще не достигли версии 0.50.

История программ

Winamp выпустил совершенно иную конфигурацию третьей версии программы, в которой отсутствовала обратная совместимость с плагинами и другими ресурсами предыдущей версии. Однако, эта версия стала полностью совместимой с версиями 2 и 3, но нумеровалась пятой, то есть 4 была пропущена… То же самое произошло с UnixWare 7, что было соединением UnixWare 2 и Open Server 5.

Как не отставать от конкурентов

   В индустрии проприетарного программного обеспечения существует общая привычка перескакивать в нумерации главных и второстепенных версий в маркетинговых целях.

   Это можно увидеть на примере нескольких продуктов Microsoft и America Online, а также в системе нумерации версий Sun Solaris, Java Virtual Machine, в версиях SCO Unix и Corel Word Perfect. Программные продукты filePro DB/RAD имели нумерацию от 2.0 к 3.0 к 4.0 к 4.1 к 4.5 к 4.8 к 5.0, и они уже готовят релиз 5.6, не имея при это ни одного промежуточного. Небольшую разницу можно заметить между версиями программного обеспечения AOL’s PC client, хотя они нумеруют только главные релизы — 5.0, 6.0, 7.0, и т.д. Таким же образом Microsoft Access перескочили от версии 2.0 к версии 7.0, чтобы догнать нумерацию версий Microsoft Word.

   У корпорации Microsoft тоже была цель догнать нумерацию версий браузера Netscape, пропустив версию 5 и выпустив сразу шестую версию Internet Explorer.

   Разработанный компанией Sun, язык программирования Java местами имел смешанную систему нумерации, при которой номер готовой версии всегда был 1.x, но три раза версия продавалась только со ссылкой на x:

• JDK 1.0.3
• JDK 1.1.2 через 1.1.8
• J2SE 1.2.0 («Java 2») через 1.4.2
• Java 1.5.0 («Java 5»)
• Java 1.6.0 («Java 6»)

Компания Sun также упустила первый номер версии Solaris, где Solaris 2.8 (или 2.9) был настоящим номером версии Solaris 8 (или 9) согласно маркетинговым документам.

Суеверия

   У релиза 2007 программы Microsoft Office был внутренний номер версии 12. Релиз Office 2010 внутренне нумеровался уже 14, из-за плохой репутации чертовой дюжины.

   Версия 13 WordPerfect Office программы Corel обозначена в продаже как «X3» (римская цифра 10 и «3»). Процедура повторилась в следующей версии X4.

Как преодолеть маркетинговые трудности

   В середине 1990х быстро развивающиеся на китайском рынке CMMS и Maximo, перескакивали от версии Maximo Series 3 сразу к Series 5, пропуская Series 4, так как неправильное произношение номера 4 на китайском языке могло означать «смерть» или «неудача». Хотя это, однако, не остановило Maximo Series 5 при выпуске релиза 4.0. Следует отметить, что на этом нумерация Series остановилась, но возобновилась вполне успешно, начиная с релиза 1.0.

Значимость нумерации версий в разработке программного обеспечения

   Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.

Использованы иллюстрации из статьи: «A successful Git branching model»

Перевод осуществлен сотрудницей компании «Chyrius» Натальей Володиной.

Известно достаточно много разработчиков, которые не могут понять как же нумеруются версии.
Иногда нужно просто сесть и разобраться, конечно в сети есть куча информации, но иногда ее слишком много, а где-то наоборот. Хочу поделиться как обстоят дела с нумерацией программного обеспечения, манера изложения понятна и доступна даже простому пользователю, которому так же не плохо знать, что же обозначают эти странные циферки после названия программы.

Формат номера версии

Формат номера версии A.B.C.D[r], где:

• A – главный номер версии (major version number).
• B – вспомогательный номер версии (minor version number).
• C – номер сборки, номер логической итерации по работе над функционалом версии A.B (build number).
• D – Номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий (SVN). Номер ревизии SVN должен синхронизироваться с номером ревизии в AssemblyInfo при каждой сборке релиза (revision number).
• [r] – условное обозначение релиза.

A.B

Совокупность главного и вспомогательного номеров версии (A.B) дают информацию о функционале приложения. Главный номер версии увеличивается только при очень серьёзном изменении функционала. Пользователи, купившие продукт и оплатившие техническую поддержку получают новые версии только в рамках постоянного главного номера версии, соответственно при выпуске новой главной версии пользователи не смогут получить её в рамках технической поддержки и будут вынуждены оплачивать её покупку заново.

C

Номер сборки (билда) (С) должен увеличиваться (зачастую) руководителем проекта по разработке всякий раз, когда продукт передаётся на тестирование.

D

Номер ревизии (D) увеличивается системой контроля версий (SVN) автоматически при работе с ней. Задача руководите проекта по разработке синхронизировать номер ревизии, генерируемый SVN, с номером указанным в AssemblyInfo в модулях проекта. Выполнять эту операцию нужно одновременно с увеличением номера билда (С).

[r]

Обозначение релиза соответствует этапу работы над проектом в рамках жизненного разработки. Выделяют следующие релизы:
• Pre-alpha (pa) – соответствует этапу начала работ над версией. Характеризуется большими изменениями в функционале и большим количеством ошибок. Pre-alpha релизы не покидают отдела разработки ПО.
• Alpha(a) – соответствует этапу завершения разработки нового функционала. Начиная с alpha версии новый функционал не разрабатывается, а все заявки на новый функционал уходят в план работ по следующей версии. Этап характеризуется высокой активностью по тестированию внутри подразделения разработки ПО и устранению ошибок.
• Beta (b) – соответствует этапу публичного тестирования. Это первый релиз, который выходит за пределы отдела разработки ПО. На этом этапе принимаются замечания от пользователей по интерфейсу продукта и прочим найденным пользователями ошибкам и неточностям.
• Release Candidate (rc) – весь функционал реализован и полностью оттестирован, все найденные на предыдущих этапах ошибки исправлены. На этом этапе могут вноситься изменения в документацию и конфигурации продукта.
• Release to manufacturing или Release to marketing (rtm) – служит для индикации того, что ПО соответствует всем требованиям качества, и готово для массового распространения. RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.
• General availability (ga) – финальный релиз, соответствующий завершению всех работ по коммерциализации продукта, продукт полностью готов к продажам через веб или на физических носителях.
• End of life (eol) – работы по развитию и поддержке продукта завершены.
В скобках указаны сокращения, используемые для формирования номера релиза. Если в номере не указано ни одного сокращения, то считается что это релиз General availability (ga).
Помимо сокращённого обозначения в наименовании версии обозначение релиза должно указываться в исходных файлах проекта через атрибут:

1

[AssemblyConfiguration]

В случае большого количества проектов в решении рекомендуется использовать один файл GlobalAssemblyInfo.cs (или GlobalAssemblyInfo.vb) с указанием ссылки на него во всех проектах решения и именно в нём проставлять вид релиза.
Пример С#:

1
2

using System.Reflection;
[assembly: AssemblyConfiguration("Beta")]

Пример VB.NET:

1

Imports System.Reflection

Примеры

HBR 2.3.1.1260b – релиз HBR версии 2.3, сборка 1, ревизия 1260, бета.
HBR 2.3.2.1370rc – релиз HBR версии 2.3, сборка 2, ревизия 1370, релиз-кандидат.
HBR 2.3.5.1432 – релиз HBR версии 2.3, сборка 5, ревизия 1432, финальный релиз.

Версии модулей/дополнение

Если в составе ПО выделены модули или дополнения, то можно применять два подхода к ведению номеров их версий.
1. Синхронная нумерация – нумерация модулей и дополнений совпадает с версией самого приложения.
2. Индивидуальная нумерация – нумерация версии модуля или дополнения ведётся индивидуально как для отдельного самостоятельного приложения.
Первый подход рекомендуется применять на этапе активной разработки приложения до выхода первого ga-релиза в текущей версии. Если функционал модуля устоялся и не требует изменений при развитии других модулей или самого приложения, то рекомендуется применять второй подход.

Имя файла дистрибутива

Имя дистрибутива должно однозначно указывать продукт и полный номер версии.
При сборке дистрибутива как набора несжатых файлов корневая папка, в которой располагаются подпапки и несжатые файлы дистрибутива именуется по формату «<Имя продукта> A_B_C_D[r]».
При сборке дистрибутива как msi-файла, msi-файл должен переименовываться в «<Имя продукта> A_B_C_D[r]».
При сжатии в архив каталога с файлами дистрибутива архив должен именоваться аналогично: «<Имя продукта> A_B_C_D[r]».
Такой принцип нумерации версий использует большинство разработчиков десктопных приложений.

Содержимое статьи чуть менее, чем полностью взято у автора https://habrahabr.ru/users/ifmalex/

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

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

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

Дональд Кнут нумерует версии системы компьютерной вёрстки ΤΕΧ последовательными приближениями числа : 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

Примечания

Разработка программного обеспечения
Известные деятели	Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Процесс	Анализ требований • Проектирование • Программирование • Тестирование • Внедрение • Сопровождение • Формальные методы • Стадии разработки
Концепции	Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
Направления	Программирование (Аспектно-ориентированное • Объектно-ориентированное • Проблемно-ориентированное) • Онтология • Сервис-ориентированная архитектура • Оценка затрат на разработку
Модели разработки	Agile • Cleanroom • CASE • Итеративная разработка • RUP • OpenUP • RAD • Scrum • MSF • Спиральная • Каскадная • XP • V-Model • Dual Vee Model • DSDM
Другие модели	CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
Прочее	Информатика • Инженерия (Компьютерная • Организационная) • История разработки ПО • Документирование • Управление (Конфигурационное • Проектами • Программами • качеством) • Эргономика • Системотехника • Обратная разработка • Версии

Нумерация версий — это процесс назначения уникального имени или цифрового номера версии уникальным состояниям ПО. В пределах категории нумерации (главное число — major, второстепенное число — minor), эти числа присваиваются в порядке возрастания соответствуют новым релизам ПО с доработками. В основе нумерации версий часто находится система управления версиями для отслеживания последовательных изменений в разных версиях электронной информации, не только для исходных кодов ПО.

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

Общие сведения

Общую информацию Вы можете получить, перейдя по следующим ссылкам:

Нумерация версий в Википедии

Нумерация версий для начинающих

Нумерация версий для пользователей Visual Basic 6.0

Расширенные сведения

С дополнительной информацией об этом понятии Вы можете ознакомиться ниже.

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

Версия 1.0 как ключевой этап разработки

Коммерческие программы, как правило, начинают нумеровать свои версии с 1.0. Считается даже, что версия 1.0 исключительно сыра и поэтому нужно как можно быстрее дойти до 1.2 или даже до 2.0.
В бесплатных и свободных программах 1.0 считается моментом, когда программа признана готовой к широкому применению неспециалистами. При этом первоначальные версии программы нумеруются как 0.1, 0.2 и т. д. FreeDOS пришёл к версии 1.0 в 2006 году — когда DOS уже практически нигде не использовался. Эмулятор игровых автоматов MAME никогда не дойдёт до версии 1.0, поскольку история игровых автоматов продолжается и поныне.

Последовательные номера

Изначально программы нумеровались числами 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 и т. д.

Алфавитно-цифровое название

Чаще всего применяется ПО с долгой историей и редко выходящими версиями. Например: Adobe Photoshop CS2, Windows Vista.

Иногда в дополнение к обычной версии используется алфавитно-цифровое подназвание: Ubuntu 9.04 Jaunty Jackalope.

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

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

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

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

Схемы нумерации

Последовательные номера

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

Ныне последовательными номерами обозначают редко выпускаемые программы, которые выходят уже стабильными. Например, Corel Draw 11, Windows 10. У таких программ мелкие сервисные изменения обычно «заметаются под ковёр», не изменяя видимой версии (меняя лишь техническую, доступную, например, из меню «О программе»). Крупные изменения с новой функциональностью, но не тянущие на новый продукт, как правило, обозначают десятичной дробью (Windows 8.1).

Десятичная дробь

Исторически первый способ нумерации, разделяющий малые и серьёзные изменения.

Номер версии является десятичной дробью в американском формате (через точку). Например, первая версия получает номер 1.0, следующая за ней — 1.1, с небольшим изменением — 1.11, создаётся новый продукт с новой функциональностью — 2.0. Чем сильнее увеличивается дробь, тем более значимо изменение. Разработчики порой перескакивают, например, от версии 2.0 сразу к 2.5, чтобы обозначить добавление нескольких значимых функций в программу, но их недостаточно, чтобы изменить главный номер версии (Turbo Pascal 5.0 → 5.5).

Для предварительных, неофициальных версий применяют числа меньше 1: скажем, 0.1 или 0.9.

Сравнение версий идёт по правилам десятичных дробей: 0.9 < 1.0 < 1.01 < 1.1 = 1.10 < 1.11 < 1.2 = 1.20 < 2.0 < 2.5.

Последовательность чисел

Этот способ принят, например, в Windows API. Версия состоит из нескольких чисел (как правило, трёх), разделённых точкой: например, 1.5.2. Первое из них — старшая версия (major), второе — младшая (minor), третья — мелкие изменения (maintenance, micro).

При увеличении одного из чисел все идущие после него сбрасываются до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1, 2.0.0… Последний ноль может опускаться: 1.0.0 = 1.0.

Библиотеки Unix используют схему версионирования current.revision.age. Current — текущий номер API, revision — счётчик версий в пределах одного API, age — разница между последней и первой версиями поддерживаемого API^[1].

Для определения старшинства версий сравнивают сначала старшие версии, потом младшие, потом микро- как целые числа: 1.1.0 = 1.1 < 1.1.2 < 1.10.0 = 1.10 < 1.11.0 < 1.20.0 < 1.100.0 < 1.100.1 < 2.0.0.

Иногда четвёртым числом идёт номер сборки со сквозной нумерацией. Эта цифра может увеличиваться на единицу с каждым выпуском (1.0.0.1 < 1.0.1.2 < 1.0.2.3 < 1.1.0.4), либо браться из какого-нибудь технического счётчика (компиляций, ночных сборок, версий кода в системе контроля версий — например, 1.5.2.7682). В Microsoft Office четвёртым числом закодирована дата выпуска^[2].

Опять-таки, 1.0 считается первой официальной версией; 0.1 или 0.9 — предварительными выпусками.

Буква в качестве младшей версии

Иногда вместо третьего числа применяется буква. Так, когда в 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.2.3 < 1.2.3r9 < 1.2.4), в то время как в официальных выпусках такого нет — например, чтобы исключить путаницу среди тестеров или выдать клиенту какую-то версию — возможно, нестабильную, но исправляющую его ошибку.

Между сериями 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.

Алфавитно-цифровое название

Чаще всего применяется ПО с долгой историей и редко выходящими версиями (Windows Vista).

Если счётчик версий зашёл слишком далеко и надо его сбросить, также используются алфавитные коды: Adobe Photoshop 7.0 < CS < CS2 < … < CS6 < CC < CC 2014.

Иногда в дополнение к обычной версии используется алфавитно-цифровое подназвание: Ubuntu 9.04 Jaunty Jackalope, Embarcadero Delphi 10.2 Tokyo.

Дата

Год выпуска применяется чаще всего в ПО с редко выходящими версиями, например: Windows Server 2003, Microsoft Office 2014.

Разработчики проекта Wine также сначала использовали даты при нумерации версий, они указывали год, месяц и день выпуска: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию выпусков, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например, выпуск октября 2010 года пронумерован как Ubuntu 10.10. Аналогичная схема на текущий период используется компанией Microsoft для нумерации обновлений Windows 10, хотя у них номер версии обычно на 1 меньше номера месяца, например, Fall Creators Update (1709) вышел 17 октября 2017 года, а April 2018 Update (1803) несмотря на номер «03» в названии вышло в апреле 2018.

При использовании дат в нумерации версий следует использовать схему ISO «год-месяц-день» (это упрощает сравнение версий на старшинство), причём дефис можно опускать.

Внутренние версии

Часто программа имеет как торговое название, так и внутреннюю версию, составленную по всем правилам. Например, Java SE 5.0 имеет внутреннюю версию 1.5.0, Windows 7 — версию 6.1^[3]. Различные сборки файлов Windows могут называться, например, 6.1.7600.16385.

Подобные технические версии сравнивают с солдатским жетоном^[2]. Как и на поле боя, они нужны в экстренных случаях — когда программа работает не так и нужно связаться с разработчиком.

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

Дональд Кнут нумерует версии системы компьютерной вёрстки ΤΕΧ последовательными приближениями числа : 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 — «крайняя плоть»^[4].

Пропуски в версиях

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

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

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

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

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

В PHP имеется специальная функция version_compare() для определения старшинства версий^[11].

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

• Dungeons & Dragons 3.5
• Крепкий орешек 4.0
• Evangelion 2.0
• Трон 2.0
• Веб 2.0
• Версия 1.0
• Наука 2.0

Внешние ссылки

• Спецификация семантического версионирования Архивная копия от 2 октября 2014 на Wayback Machine (SemVer)

См. также

• Система управления версиями
• Стадии разработки программного обеспечения

Примечания

Эта страница в последний раз была отредактирована 11 марта 2022 в 15:40.

Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.