Управление версиями программного обеспечения - Software versioning

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

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

Схемы

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

Идентификаторы на основе последовательности

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

Изменить значение

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

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

Семантическое управление версиями (также известное как SemVer), в настоящее время наиболее известная и наиболее широко используемая схема версий в этой категории, использует последовательность из трех цифр (Major.Minor.Patch), дополнительный тег предварительной версии и дополнительный метатег сборки. В этой схеме мерами значимости являются риск и функциональность. Критические изменения обозначаются увеличением основного числа (высокий риск), новые неразрывные функции увеличивают второстепенное число (средний риск), а все другие неразрывные изменения увеличивают номер исправления (самый низкий риск). Наличие тега перед выпуском (-alpha, -beta) указывает на существенный риск, как и большое число, равное нулю (0.yz), которое используется для обозначения незавершенной работы, которая может содержать любой уровень потенциально критические изменения (самый высокий риск).

Разработчики могут выбрать одновременный переход к нескольким дополнительным версиям, чтобы указать, что были добавлены важные функции, но этого недостаточно, чтобы гарантировать увеличение номера основной версии; например Internet Explorer 5 от 5.1 до 5.5 или Adobe Photoshop 5 до 5.5. Это может быть сделано для того, чтобы подчеркнуть ценность обновления для пользователя программного обеспечения или, как в случае с Adobe, для представления выпуска на полпути между основными версиями (хотя уровни управления версиями на основе последовательности не ограничиваются одной цифрой, как в версии Blender . 2.79).

Другой подход - использовать старший и младший номера вместе с буквенно-цифровой строкой, обозначающей тип выпуска, например, «альфа» (a), «бета» (b) или «кандидат на выпуск» (rc). Выпуск программного обеспечения поезд с использованием этого подхода может выглядеть 0,5, 0,6, 0,7, 0,8, 0,9 → 1.0b1, 1.0b2 (с некоторыми исправлениями), 1.0b3 (с большим количеством исправлений) → 1.0rc1 (который, если он устойчив достаточно ) , 1.0rc2 (если найдены другие ошибки) → 1.0. Обычной практикой в ​​этой схеме является блокирование новых функций и критических изменений на этапах выпуска-кандидата, а для некоторых команд даже бета-версии привязаны только к исправлениям ошибок, чтобы обеспечить согласованность с целевым выпуском.

Другие схемы придают значение отдельным последовательностям:

major.minor [.build [.revision]] (пример: 1.2.12.102 )

major.minor [.main maintenance [.build]] (пример: 1.4.3.5249 )

Опять же, в этих примерах определение того, что составляет «основное», а не «незначительное» изменение, полностью субъективно и зависит от автора, как и то, что определяет «сборку» или чем «ревизия» отличается от "незначительное" изменение.

Общие библиотеки в Solaris и Linux могут использовать формат current.revision.age , где:

current : Самый последний номер интерфейса, который реализует библиотека.

revision : номер реализации текущего интерфейса.

age : разница между самым новым и самым старым интерфейсами, реализуемыми библиотекой. Это использование третьего поля специфично для libtool : другие могут использовать другое значение или просто игнорировать его.

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

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

Степень совместимости

Семантическое управление версиями, состоящее из трех частей

В некоторых проектах номер основной версии используется для обозначения несовместимых выпусков. Двумя примерами являются Apache Portable Runtime (APR) и FarCry CMS .

Семантическое управление версиями - это формальное соглашение для определения совместимости с использованием номера версии из трех частей: основная версия; минорная версия; и патч. Номер патча увеличивается для незначительных изменений и исправлений ошибок, которые не меняют интерфейс прикладного программирования (API) программного обеспечения. Дополнительная версия увеличивается для выпусков, которые добавляют новые, но обратно совместимые, функции API, а основная версия увеличивается для изменений API, которые не имеют обратной совместимости. Например, программное обеспечение, основанное на версии 2.1.5 API, совместимо с версией 2.2.3, но не обязательно с 3.2.4.

Часто программисты пишут новое программное обеспечение для обеспечения обратной совместимости , т. Е. Новое программное обеспечение предназначено для правильного взаимодействия со старыми версиями программного обеспечения (с использованием старых протоколов и форматов файлов) и самой последней версией (с использованием новейших протоколов и форматов файлов). Например, IBM z / OS предназначена для правильной работы с тремя последовательными основными версиями операционной системы, работающими в одном сисплексе. Это позволяет людям, использующим кластер компьютеров с высокой доступностью, поддерживать большинство компьютеров в рабочем состоянии, в то время как по одной машине за один раз выключается, обновляется и восстанавливается для работы.

Часто заголовки пакетов и формат файла включают номер версии - иногда такой же, как номер версии программного обеспечения, которое его написало; в других случаях «номер версии протокола» независимо от номера версии программного обеспечения. Код для обработки устаревших протоколов и форматов файлов часто рассматривается как бесполезный .

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

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

Для обозначения статуса более новой версии используется ряд схем:

• Буквенно-цифровой суффикс - это обычная схема, принятая semver. В этой схеме версии помечены тире и некоторыми буквенно-цифровыми символами для обозначения статуса.
• Числовой статус - это схема, в которой числа используются для обозначения статуса, как если бы он был частью последовательности. Типичный выбор - третья позиция для четырехпозиционного управления версиями.
• Numeric 90+ - это еще одна схема, в которой используются числа, но, очевидно, под номером в предыдущей версии. В последней позиции используется большое число, обычно 90 или больше. Это обычно используется более старыми проектами с открытым исходным кодом, такими как GNOME и Fontconfig .

Две чисто числовые формы удаляют специальную логику, необходимую для обработки сравнения «alpha <beta <rc <no prefix», как в semver, за счет ясности. (Семвер фактически не указывает конкретных терминов для стадий разработки; сравнение просто в лексикографическом порядке .)

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

Есть две школы мысли относительно того, как увеличиваются числовые номера версий. Большинство бесплатных программных пакетов с открытым исходным кодом , включая MediaWiki , рассматривают версии как серию отдельных чисел, разделенных точками, с последовательностью, например 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 и т. Д.

С другой стороны, некоторые программные пакеты идентифицируют выпуски по десятичным числам: 1.7, 1.8, 1.81, 1.82, 1.9 и т. Д. Десятичные версии были распространены в 1980-х годах, например, с NetWare , DOS и Microsoft Windows , но даже в 2000-х. например, использовались Opera и Movable Type . В десятичной схеме 1.81 - это второстепенная версия, следующая за 1.8, тогда как служебные выпуски (т. Е. Только исправления ошибок) могут быть обозначены буквенным суффиксом, например 1.81a или 1.81b.

Стандартная схема нумерации версий GNU - major.minor.revision, но Emacs является ярким примером использования другой схемы, где старший номер (1) был удален, и была добавлена ​​редакция сайта пользователя, которая всегда равна нулю в исходных пакетах Emacs, но увеличена дистрибьюторами. . Точно так же номера пакетов Debian начинаются с необязательного префикса «эпохи», который используется для изменения схемы управления версиями.

Сброс

В некоторых случаях разработчики могут решить сбросить основной номер версии. Иногда это используется для обозначения выпуска новой фазы разработки. Например, Minecraft Alpha работал с версии 1.0.0 до 1.2.6, а когда была выпущена бета-версия, она сбрасывала основной номер версии и работала с 1.0 до 1.8. Когда игра была полностью выпущена, основной номер версии снова сбрасывается до 1.0.0.

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

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

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

Когда точка используется для разделения последовательностей, она может представлять или не представлять десятичную точку, - см. Раздел « Приращение последовательностей » для различных стилей интерпретации.

Количество последовательностей

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

Использование отрицательных чисел

В некоторых проектах используются отрицательные номера версий. Одним из примеров является компилятор SmartEiffel, который запускается с -1,0 и ведет счет вверх до 0,0.

Дата выпуска

Заставка Street Fighter EX с номером версии в формате CalVer

Многие проекты используют схему управления версиями на основе даты, которая называется Calendar Versioning (также известная как CalVer). Ubuntu Linux - один из примеров проекта, использующего управление версиями календаря; Например, Ubuntu 18.04 был выпущен в апреле 2018 года. Его преимущество заключается в том, что его легко связать с графиками разработки и сроками поддержки. Некоторые видеоигры также используют дату в качестве версии, например, аркадная игра Street Fighter EX . При запуске он отображает номер версии в виде даты плюс код региона, например 961219 ASIA .

При использовании дат в управлении версиями, например, именах файлов, обычно используется схема ISO 8601 : ГГГГ-ММ-ДД, поскольку это легко сортируемая строка в порядке возрастания / убывания. Иногда дефисы опускаются. Вино проект ранее использовал дату контроля версий схемы, которая использовала год и месяц , за которым следует день освобождения; например, «Вино 20040505».

Номера сборок Microsoft Office представляют собой закодированную дату: первые две цифры указывают количество месяцев, прошедших с января года, в котором был запущен проект (при этом каждый основной выпуск Office представляет собой отдельный проект), а последние две цифры указывают день этого месяца. Таким образом, 3419 - это 19-й день 34-го месяца после января года, в котором проект был запущен.

Другие примеры, которые определяют версии по годам, включают Adobe Illustrator 88 и WordPerfect Office 2003 . Когда для обозначения версии используется дата, это обычно используется в маркетинговых целях, и также существует фактический номер версии. Например, Microsoft Windows 95 имеет внутреннюю версию MS-DOS 7.00 и Windows 4.00; аналогично, Microsoft Windows 2000 Server имеет внутреннюю версию Windows NT 5.0 («NT» является ссылкой на исходное название продукта).

Python

Фонд программного обеспечения Python опубликовал PEP 440 - спецификацию идентификации версий и зависимостей , в которой излагается собственная гибкая схема, определяющая сегмент эпохи, сегмент выпуска, сегменты до и после выпуска и сегмент выпуска разработки.

TeX

TeX имеет особую систему нумерации версий. Начиная с версии 3, обновления обозначались добавлением дополнительной цифры в конце, так что номер версии асимптотически приближался к π ; это форма унарной нумерации - номер версии - это количество цифр. Текущая версия - 3.14159265. Это свидетельствует о том, что TeX очень стабилен, и ожидаются лишь незначительные обновления. Разработчик TeX Дональд Кнут заявил, что «абсолютно окончательное изменение (которое будет сделано после [его] смерти)» будет заключаться в изменении номера версии на π, после чего все оставшиеся ошибки станут постоянными функциями.

Аналогичным образом номер версии METAFONT асимптотически приближается к e .

яблоко

У Apple есть формализованная структура номера версии, основанная на структуре NumVersion, которая определяет основную версию с одной или двумя цифрами, вспомогательную версию с одной цифрой, версию с «ошибкой» (т. Е. Ревизию) с одной цифрой, индикатор стадии (нарисованный из набора development / prealpha, alpha, beta и final / release) и однобайтовой (т.е. имеющей значения в диапазоне 0–255) предварительной версии, которая используется только на стадиях, предшествующих финальной. При записи этих номеров версий в виде строк принято опускать любые части после второстепенной версии, значение которых равно нулю (при этом «final» считается нулевым этапом), таким образом записывая 1.0.2 (а не 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 2000 Microsoft создала семейство Windows Server, которое продолжило годовой стиль с отличием: для второстепенных выпусков Microsoft добавляла суффикс «R2» к названию, например, Windows Server 2008 R2 (версия 6.1). Этот стиль сохранился до сих пор. Однако клиентские версии Windows не приняли единого стиля. Во-первых, они получили имена с произвольными буквенно-цифровыми суффиксами, как в Windows ME (4.90), Windows XP (5.1) и Windows Vista (6.0). Затем Microsoft снова ввела в заголовок инкрементные номера, но на этот раз это были не номера версий; номера версий Windows 7 , Windows 8 и Windows 8.1 - соответственно 6.1, 6.2 и 6.3. В Windows 10 номер версии подскочил до 10.0, а последующие обновления ОС увеличили только номер сборки и номер версии обновления сборки (UBR).

Другие схемы

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

BLAG Linux и GNU имеют очень большие номера версий: основные выпуски имеют номера, такие как 50000 и 60000, тогда как второстепенные выпуски увеличивают номер на 1 (например, 50001, 50002). Альфа- и бета-выпускам присваиваются десятичные номера версий, немного меньшие, чем номер основного выпуска, например, 19999.00071 для альфа-1 версии 20000 и 29999.50000 для бета-2 версии 30000. Начиная с 9001 в 2003 году, самая последняя версия по состоянию на 2011 год - 140000.

Внутренние номера версий

Программное обеспечение может иметь «внутренний» номер версии, который отличается от номера версии, указанного в названии продукта (и который обычно более последовательно соответствует правилам нумерации версий). Java SE 5.0, например, имеет внутренний номер версии 1.5.0, а версии Windows, начиная с NT 4, продолжали внутренние числовые стандартные версии: Windows 2000 - это NT 5.0, XP - это Windows NT 5.1, Windows Server 2003 и Windows. XP Professional x64 Edition - NT 5.2, Windows Server 2008 и Vista - NT 6.0, Windows Server 2008 R2 и Windows 7 - NT 6.1, Windows Server 2012 и Windows 8 - NT 6.2, а Windows Server 2012 R2 и Windows 8.1 - NT 6.3, однако первая версия Windows 10 была 10.0 (10.0.10240). Обратите внимание, однако, что Windows NT находится только в пятой основной редакции, так как ее первый выпуск имел номер 3.1 (чтобы соответствовать текущему номеру выпуска Windows), а при запуске Windows 10 произошел скачок версии с 6.3 до 10.0.

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

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

Программы, которые находятся на ранней стадии, часто называют «альфа-программами», после первой буквы греческого алфавита. После того как они созреют, но еще не готовы к выпуску, их можно назвать «бета-версиями» после второй буквы греческого алфавита. Как правило, альфа-версия программного обеспечения тестируется только разработчиками, а бета-версия распространяется для тестирования сообществом.

Некоторые системы используют числовые версии меньше 1 (например, 0.9), чтобы предложить свой подход к окончательному выпуску "1.0". Это обычное соглашение в программном обеспечении с открытым исходным кодом . Однако, если предварительная версия предназначена для существующего программного пакета (например, версия 2.5), то к номеру версии может быть добавлена ​​буква «а» или «альфа». Таким образом, альфа-версия выпуска 2.5 может обозначаться как 2.5a или 2.5.a.

Альтернативный вариант - называть предварительные версии «кандидатами на выпуск», чтобы программные пакеты, которые вскоре будут выпущены в качестве конкретной версии, могут содержать этот тег версии, за которым следует «rc- #», указывающий номер кандидата на выпуск. ; при выпуске финальной версии тег «rc» удаляется.

Отпустить поезд

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

В программной платформе Cisco IOS на протяжении многих лет использовался график выпуска релизов с множеством отдельных поездов. Совсем недавно ряд других платформ, включая Firefox и Fenix ​​для Android, Eclipse , LibreOffice , Ubuntu , Fedora, Python, digiKam и VMware , приняли модель поезда выпуска.

Модификации числовой системы

Версии с нечетными номерами для разрабатываемых выпусков

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

Та же система нечет-четность используется некоторым другим программным обеспечением с длинными циклами выпуска, таким как Node.js до версии 0.12, а также GNOME и WineHQ .

яблоко

В эпоху классической Mac OS у Apple были свои собственные изменения в этой привычке . В отличие от традиционной нумерации версий (где 1.5 не находится посередине между 1.0 и 2.0, учитывая, что может быть любое количество второстепенных выпусков, например, 1.22), классические второстепенные версии Apple Mac OS редко выходили за пределы пункта-1. Когда они это сделали, они дважды прыгнули прямо к пункту 5, предполагая, что выпуск был «более значительным». Полная последовательность классических версий Mac OS (не включая патчи): 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. Таким образом, «8.5» превратилось в собственный коммерческий выпуск, означающий «восемь с половиной», а 8.6, фактически, как «8.5.1».

Mac OS X (переименованная в macOS ) отошла от этой тенденции во многом потому, что в названии продукта стоит буква «X» (римская цифра 10). В результате все версии OS X начинаются с номера 10. Первому основному выпуску OS X был присвоен номер версии 10.0, но следующему основному выпуску был не 11.0. Вместо этого она называлась версией 10.1, за которой следовали 10.2, 10.3 и так далее для каждого последующего основного выпуска.

В этой системе третье число (вместо второго) обозначает второстепенный выпуск, а четвертое число (вместо третьего) обозначает выпуски с исправлениями ошибок / исправлениями. Поскольку первое число всегда равно 10, а последующие числа являются не десятичными, а целыми числами, 11-я основная версия OS X помечена как «10.10», а не «11.0». Несмотря на то, что буква «X» была исключена из названия в macOS 10.12 , эта схема нумерации продолжалась и в macOS 10.15. Следующий выпуск MacOS от Apple, предварительно получивший номер 10.16, был официально объявлен как macOS 11.0 на WWDC в июне 2020 года.

Политическое и культурное значение номеров версий

Версия 1.0 как веха

В свободно-программном обеспечении и с открытым исходным кодом сообщества , как правило , к выпуску программного обеспечения рано и часто . Первоначальные версии имеют номера меньше 1, причем эти версии 0.x используются для обозначения того, что программное обеспечение является неполным и недостаточно надежным для общего выпуска или может использоваться в его текущем состоянии.

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

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

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

Некоторые поставщики программного обеспечения даже заходят так далеко, что требуют применения так называемых «ежедневных исправлений» до того, как программное обеспечение будет работать должным образом или выпустит новые функции и функции через [[DLC (загружаемый контент) |] Загружаемый контент], иногда включая базовые основные функции и функции, которые иногда можно утверждать, что они должны были быть включены в первоначальный выпуск «Версия 1.0».

Номера версий как маркетинг

Относительно распространенная практика - резко увеличивать количество версий по маркетинговым причинам. Иногда поставщики программного обеспечения просто обходят выпуск 1.0 или быстро выпускают выпуск с последующим номером версии, потому что многие клиенты считают программное обеспечение 1.0 слишком незрелым, чтобы доверять его производственным развертываниям. Например, как и в случае с dBase II , продукт запускается с номером версии, который подразумевает, что он более зрелый, чем он есть;

В других случаях номера версий увеличиваются, чтобы соответствовать номерам конкурентов. Это можно увидеть на многих примерах нумерации версий продуктов Microsoft, America Online , Sun Solaris , Java Virtual Machine , SCO Unix, WordPerfect . Microsoft Access перешел с версии 2.0 на версию 7.0, чтобы соответствовать номеру версии Microsoft Word .

Microsoft также была целью «догоняющего» управления версиями, когда браузеры Netscape пропускали версии с 5 по 6 в соответствии с Microsoft Internet Explorer , но также потому, что пакет приложений Mozilla унаследовал версию 5 в строке своего пользовательского агента во время до 1.0. development, а Netscape 6.x был построен на базе кода Mozilla.

Другой пример не отставания от конкурентов - это переход Slackware Linux с версии 4 на версию 7 в 1999 году.

яблоко

У Apple есть особая форма пропуска номера версии: она использовала римскую цифру X в маркетинге нескольких продуктовых линеек. И QuickTime, и Final Cut Pro перешли с версии 7 непосредственно на версию 10. Как и в случае с Mac OS X , продукты представляли собой не обновления предыдущих версий, а совершенно новые программы под маркой QuickTime X и Final Cut Pro X , но в отличие от настольных компьютеров Apple. В системах не было основных версий 8 или 9. Однако, как и в случае с OS X , второстепенные выпуски обозначаются третьей цифрой, а не второй. Следовательно, в основных выпусках этих программ также используется вторая цифра, как это делает Apple с OS X. На WWDC 2016 они объявили, что Mac OS X была переименована в macOS .

Удаление наиболее значимого элемента

Java Sun иногда имела гибридную систему, в которой внутренний номер версии всегда был 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, 1.6.0, 1.7.0, 1.8.0 («Java 5, 6, 7, 8»)

Sun также опустила первую цифру для Solaris, где Solaris 2.8 (или 2.9) в маркетинговых материалах упоминается как Solaris 8 (или 9).

Аналогичный скачок произошел с конструктором АТС с открытым исходным кодом Asterisk в начале 2010-х годов, руководители проекта которого объявили, что за текущей версией 1.8.x вскоре последует версия 10.

Этот подход, который многие осуждают из-за того, что он нарушает семантическую значимость разделов номера версии, был принят все большим числом поставщиков, включая Mozilla (для Firefox).

Суеверие

• Выпуск Microsoft Office для Office 2007 имеет внутренний номер версии 12. Следующая версия, Office 2010, имеет внутреннюю версию 14 из-за предрассудков, окружающих номер 13 . Visual Studio 2013 - это версия продукта под номером 12.0, а новая версия Visual Studio 2015 имеет номер версии 14.0 по тем же причинам.
• Roxio Toast перешел с версии 12 на версию 14, вероятно, в попытке избавиться от суеверий, связанных с числом 13.
• Corel «s WordPerfect Office , версия 13 позиционируется как "X3"( римская цифра 10 и "3"). Процедура была продолжена в следующей версии, X4. То же самое произошло с Corel Graphic Suite (т.е. CorelDRAW , Corel Photo-Paint ), а также с его программным обеспечением для редактирования видео «Video Studio».
• Sybase пропустила основные версии 13 и 14 в своем продукте реляционной базы данных Adaptive Server Enterprise, переместившись с 12.5 на 15.0.
• ABBYY Lingvo Dictionary использует нумерацию 12, x3 (14), x5 (15).
• SUSE Linux Enterprise пропустил версии 13 и 14 после версии 12 и сразу выпустил SLES 15 в июле 2018 года.

Компьютерная культура

• SUSE Linux распределение началось в версии 4.2, чтобы ссылаться на 42 , «ответ на главный вопрос жизни, вселенной и все» , упомянутые в Дугласа Адамса " Автостопом по Галактике .
• Версия Slackware Linux была 13.37, со ссылкой на leet .
• Finnix пропустил версию 93.0 до 100, отчасти для того, чтобы выполнить утверждение «Finnix '95 не будет», ссылку на Windows 95 .
• Спецификация формата файлов изображений с тегами использовала 42 в качестве внутреннего номера версии с момента своего создания, и разработчики не ожидали, что они будут больше изменять его в течение их (или его) срока службы, поскольку это будет противоречить его директивам разработки.

Преодоление предполагаемых маркетинговых трудностей

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

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

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

В 21 веке все больше программистов начали использовать формализованную политику версий, такую ​​как политика семантического управления версиями. Цель таких политик - помочь другим программистам узнать, когда изменения кода могут нарушить то, что они написали. Такие политики особенно важны для программных библиотек и фреймворков , но также могут быть очень полезны для выполнения для приложений командной строки (которые могут быть вызваны из других приложений) и, действительно, любых других приложений (которые могут быть написаны сценариями и / или расширены третьими сторонами. ).

Управление версиями также является необходимой практикой для включения многих схем установки исправлений и обновления программного обеспечения, особенно для автоматического решения, что и где обновлять.

Значение в технической поддержке

Номера версий позволяют людям, предоставляющим поддержку, точно определить , какой код запускает пользователь, чтобы они могли исключить ошибки, которые уже были исправлены как причину проблемы, и тому подобное. Это особенно важно, когда у программы есть значительное сообщество пользователей, особенно когда это сообщество достаточно велико, чтобы люди, обеспечивающие техническую поддержку, не были людьми, написавшими код. Семантическое значение нумерации стиля version.revision.change также важно для сотрудников информационных технологий, которые часто используют его, чтобы определить, сколько внимания и исследований им необходимо уделить новому выпуску перед его развертыванием на своем предприятии. Как показывает практика, чем больше изменения, тем выше вероятность того, что что-то может сломаться (хотя изучение журнала изменений, если таковой имеется, может выявить только поверхностные или несущественные изменения). Это одна из причин неприязни, выраженной в подходе Asterisk et alia «отказаться от основного выпуска»: теперь сотрудники должны (или, по крайней мере, должны) проводить полный регрессионный тест для каждого обновления.

Номера версий для файлов и документов

Некоторые компьютерные файловые системы , такие как файловая система OpenVMS , также хранят версии файлов.

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

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

Номера версий очень быстро эволюционируют от простых целых чисел (1, 2, ...) к рациональным числам (2.08, 2.09, 2.10), а затем к нечисловым «числам», таким как 4: 3.4.3-2. Поэтому эти сложные номера версий лучше рассматривать как символьные строки. Операционные системы, которые включают средства управления пакетами (такие как все нетривиальные дистрибутивы Linux или BSD ), будут использовать специфичный для дистрибутива алгоритм для сравнения номеров версий различных пакетов программного обеспечения. Например, алгоритмы упорядочивания Red Hat и производных дистрибутивов отличаются от таковых в дистрибутивах, подобных Debian.

В качестве примера неожиданного поведения реализации порядка номеров версий в Debian начальные нули игнорируются в кусках, так что 5.0005 и 5.5 считаются равными, а 5.5  <  5.0006. Это может запутать пользователей; инструменты сопоставления строк могут не найти заданный номер версии; и это может вызвать небольшие ошибки в управлении пакетами, если программисты используют структуры данных с индексированными строками, такие как хеш-таблицы с индексами по номерам версий.

Чтобы упростить сортировку, некоторые программные пакеты представляют каждый компонент схемы major.minor.release с фиксированной шириной. Perl представляет номера версий в виде числа с плавающей запятой; например, выпуск Perl 5.8.7 также может быть представлен как 5.008007. Это позволяет представить теоретическую версию 5.8.10 как 5.008010. Другие пакеты программного обеспечения упаковывают каждый сегмент в фиксированную разрядность; например, в Microsoft Windows номер версии 6.3.9600.16384 будет представлен в шестнадцатеричном формате 0x0006000325804000. Схема с плавающей точкой перестает работать, если какой-либо сегмент номера версии превышает 999; двоично-упакованная схема, использующая 16 битов, не работает после 65535.

Использование в других СМИ

Номера версий программного обеспечения можно найти на других носителях.

В некоторых случаях это прямая аналогия (например: Jackass 2.5 , версия Jackass Number Two с дополнительными специальными функциями; второй альбом Garbage под названием Version 2.0 ; или Dungeons & Dragons 3.5, где правила были пересмотрены с третье издание, но не настолько, чтобы считаться четвертым).

Чаще он используется для обозначения ассоциации с высокими технологиями и буквально не указывает на «версию» (например, Tron 2.0 , продолжение видеоигры к фильму Tron или телесериал The IT Crowd , который относится к второй сезон как версия 2.0). Особенно примечательным является использование Web 2.0 , относящееся к веб-сайтам начала 2000-х годов, которые делали упор на пользовательский контент , удобство использования и совместимость .

Смотрите также

Ссылки

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

• 3 эффективных метода контроля версий программного обеспечения
• Практическое руководство по выпуску программного обеспечения
• Нумерация версий программного обеспечения
• План выпуска Document Foundation для LibreOffice, показывающий этапы выпуска