Из Википедии, бесплатной энциклопедии
  (Перенаправлено с номера версии )
Перейти к навигации Перейти к поиску

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

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

Схемы [ править ]

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

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

Version number sequence

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

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

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

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

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

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

Другой подход заключается в использовании основного и вспомогательного номеров вместе с буквенно-цифровой строкой, обозначающей тип выпуска, например «альфа» (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 , где: [3] [4]

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

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

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

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

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

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

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

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

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

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

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

  • Буквенно-цифровой суффикс - это общая схема, принятая для семантического управления версиями. [1] В этой схеме версии отмечены тире и некоторыми буквенно-цифровыми символами для обозначения статуса.
  • Числовой статус - это схема, в которой числа используются для обозначения статуса, как если бы он был частью последовательности. Типичный выбор - третья позиция для четырехпозиционного управления версиями.
  • Numeric 90+ - это еще одна схема, в которой используются числа, но, очевидно, под номером предыдущей версии. В последней позиции используется большое число, обычно 90 или больше. Это обычно используется более старыми проектами с открытым исходным кодом, такими как GNOME и Fontconfig .
Сравнение показателей стадии разработки
ЭтапSemverNum. СтатусNum 90+
Альфа1.2.0-a.11.2.0.11.1.90
Бета1.2.0-b.21.2.1.21.1.93
Релиз-кандидат1.2.0-rc.31.2.2.31.1.97
Релиз1.2.01.2.3.01.2.0
Пост-релизные исправления1.2.51.2.3.51.2.5

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

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

Есть две точки зрения относительно того, как увеличиваются числовые номера версий. Большинство бесплатных программных пакетов с открытым исходным кодом , включая 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 [8] и Movable Type . [9] В десятичной схеме 1.81 - это второстепенная версия, следующая за 1.8, а служебные выпуски (т. Е. Только исправления ошибок) могут обозначаться буквенным суффиксом, например 1.81a или 1.81b.

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

Сброс

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

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

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

  • Схема может использовать один и тот же символ во всех последовательностях: 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. [11]

Дата выпуска [ править ]

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

Многие проекты используют схему управления версиями на основе даты, которая называется Calendar Versioning (также известная как CalVer [14] ).

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

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

Номера сборок Microsoft Office представляют собой закодированную дату: [16] первые две цифры указывают количество месяцев, прошедших с января года, в котором был запущен проект (причем каждый основной выпуск 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 [ править ]

Foundation Python Software опубликовал PEP 440 - Версия для идентификации и зависимости Спецификации , [17] с изложением своей собственной гибкой схемы, которая определяет сегмент эпохального, сегмент выхода, пру-релиз и пост-релиз сегменты и сегмент выпуска развития.

TeX [ править ]

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

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

Apple [ править ]

В эпоху классической Mac OS номера дополнительных версий редко выходили за пределы «.1». Когда они это делали, они обычно прыгали прямо до «0,5», предполагая, что выпуск был «более значительным». [a] Таким образом, «8.5» продавалась как отдельный выпуск, представляющий «Mac OS 8 с половиной», а 8.6 фактически означал «8.5.1».

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

Римская цифра X одновременно использовалась в маркетинговых целях для нескольких продуктовых линеек. И QuickTime, и Final Cut Pro перешли с версии 7 непосредственно на версию 10, QuickTime X и Final Cut Pro X. Как и сама Mac OS X, продукты были не обновлениями до предыдущих версий, а совершенно новыми программами. Как и в случае с OS X, в основных выпусках этих программ вторая цифра увеличивалась, а второстепенные версии обозначались третьей цифрой. Буква «X» была исключена из названия Final Cut с выпуском macOS 11.0 (см. Ниже), а брендинг QuickTime стал спорным, когда фреймворк был заменен AVFoundation в 2011 году (программа для воспроизведения видео QuickTime называлась только QuickTime Player из начало).

Следующий выпуск macOS от Apple, предварительно пронумерованный 10.16, [20] был официально объявлен как macOS 11.0 на WWDC в июне 2020 года [21].

Microsoft Windows [ править ]

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 [22] и последующие обновления ОС только увеличенный номер сборки и номер версии обновления сборки (UBR).

Другие схемы [ править ]

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

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

Urbit использует управление версиями по Кельвину (названное в честь абсолютной температурной шкалы Кельвина ): версии программного обеспечения начинаются с большого числа и ведутся обратный отсчет до версии 0, после чего программное обеспечение считается завершенным и дальнейшие изменения не производятся. [27] [28]

Внутренние номера версий [ править ]

Программное обеспечение может иметь «внутренний» номер версии, который отличается от номера версии, указанного в названии продукта (и который обычно более последовательно соответствует правилам нумерации версий). 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". Это обычное соглашение в программном обеспечении с открытым исходным кодом . [29] [30] Однако, если предварительная версия предназначена для существующего программного пакета (например, версия 2.5), то к номеру версии может быть добавлена ​​буква «а» или «альфа». Таким образом, альфа-версия выпуска 2.5 может обозначаться как 2.5a или 2.5.a.

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

Освободить поезд [ править ]

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

Программная платформа Cisco IOS в течение многих лет использовала график выпуска релизов с множеством отдельных поездов. Совсем недавно появился ряд других платформ, включая Firefox и Fenix ​​для Android, [31] Eclipse , [32] LibreOffice , [33] Ubuntu , [34] Fedora, [35] Python, [36] digiKam [37] и VMware [ 38] приняли модель поезда выпуска.

Изменения в системе счисления [ править ]

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

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

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

Версия 1.0 как веха [ править ]

В свободно-программном обеспечении и с открытым исходным кодом сообщества , как правило , к выпуску программного обеспечения рано и часто . Первоначальные версии имеют номера меньше 1, причем эти версии 0.x используются для обозначения того, что программное обеспечение является неполным и недостаточно надежным для общего выпуска или может использоваться в его текущем состоянии. Изменения, несовместимые с предыдущими версиями, обычны для версий 0.x. Версия 1.0 используется в качестве важной вехи , указывая на то, что программное обеспечение имеет по крайней мере все основные функции плюс функции, которые разработчики хотели получить в этой версии, и считается достаточно надежным для общего выпуска. [29] [30] Хорошим примером этого является ядро ​​Linux, которое было впервые выпущено как версия 0.01 в 1991 году, [40]и потребовалось до 1994 года, чтобы достичь версии 1.0.0. [41]

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

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

Номера версий как маркетинговые [ править ]

Относительно распространенной практикой является резкий скачок номеров версий по маркетинговым причинам. Иногда поставщики программного обеспечения просто обходят выпуск 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 году. [43]

Удаление наиболее значимого элемента [ править ]

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

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

Суеверие [ править ]

  • У выпуска Microsoft Office 2007 был внутренний номер версии 12. Следующая версия, Office 2010, имеет внутреннюю версию 14 из-за предрассудков, окружающих номер 13 . [45] Visual Studio 2013 - это версия продукта под номером 12.0, а новая версия Visual Studio 2015 имеет номер версии 14.0 по тем же причинам. [46] [ циркулярная ссылка ]
  • 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 . [47]
  • Спецификация формата файлов изображений с тегами с самого начала использовала 42 в качестве внутреннего номера версии , [ когда? ] его разработчики не ожидают, что будут изменять его больше в течение их (или его) жизни, поскольку это будет противоречить [ по мнению кого? ] с его директивами по развитию.

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

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

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

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

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

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

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

Номера версий позволяют людям, предоставляющим поддержку, точно определить , какой код запускает пользователь, чтобы они могли исключить ошибки, которые уже были исправлены как причину проблемы, и тому подобное. Это особенно важно, когда программа имеет значительное сообщество пользователей, особенно когда это сообщество достаточно велико, чтобы люди, обеспечивающие техническую поддержку, не были людьми, написавшими код. Смысловое значение [1]нумерации в стиле 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.

Использование в других средствах массовой информации [ править ]

Software-style version numbers can be found in other media.

In some cases, the use is a direct analogy (for example: Jackass 2.5, a version of Jackass Number Two with additional special features; the second album by Garbage, titled Version 2.0; or Dungeons & Dragons 3.5, where the rules were revised from the third edition, but not so much as to be considered the fourth).

More often it's used to play on an association with high technology, and doesn't literally indicate a 'version' (e.g., Tron 2.0, a video game followup to the film Tron, or the television series The IT Crowd, which refers to the second season as Version 2.0). A particularly notable usage is Web 2.0, referring to websites from the early 2000s that emphasized user-generated content, usability and interoperability.

Phish 1.0, 2.0, 3.0 and possibly 4.0 after the Covid 19 forced hiatus.

See also[edit]

  • Continuous data protection
  • Maintenance release
  • Product life cycle management
  • Release management
  • Release notes
  • Software engineering

Notes[edit]

  1. ^ The complete sequence of classic Mac OS versions (not including patches) is: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (skipping 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 (jumped), 8.6, 9.0, 9.1, 9.2.

References[edit]

  1. ^ a b c d e f g Preston-Werner, Tom (2013). Semantic Versioning 2.0.0. Creative Commons. Retrieved from https://semver.org/spec/v2.0.0.html.
  2. ^ Lam, Patrick; Dietrich, Jens; Pearce, David J. (2020-08-16). "Putting the Semantics into Semantic Versioning". arXiv:2008.07069 [cs.SE].
  3. ^ "Library Interface Versioning in Solaris and Linux".
  4. ^ "Libtool's versioning system". Libtool documentation.
  5. ^ "Versioning Numbering Concepts - The Apache Portable Runtime Project". Retrieved 2009-04-11.
  6. ^ "Daemonite: The science of version numbering". 2004-09-14. Retrieved 2009-04-11.
  7. ^ Frank Kyne, Bert de Beer, Luis Martinez, Harriet Morril, Miha Petric, David Viguers, Suzi Wendler. "System z Parallel Sysplex Best Practices". 2011. p. 6.
  8. ^ "Opera Changelogs for Windows". Opera Software. 2014. Retrieved November 6, 2014.
  9. ^ "Home". Movable Type Documentation Wiki. June 25, 2013. Retrieved November 6, 2014.
  10. ^ "GNU Coding Standards: Releases". GNU Project. 2014-05-13. Retrieved 2014-05-25. You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers, but it is very unlikely that you really need them.
  11. ^ a b "Advogato: Version numbering madness". 2000-02-28. Retrieved 2009-04-11.
  12. ^ Debian Policy Manual, 5.6.12 Version
  13. ^ "Java Edition version history". Official Minecraft Wiki. Retrieved 2019-03-06.
  14. ^ "Calendar Versioning — CalVer". calver.org. Retrieved 2019-10-10.
  15. ^ Markus Kuhn (2004-12-19). "International standard date and time notation". University of Cambridge. Retrieved 2009-04-11.
  16. ^ Jeff Atwood (2007-02-15). "Coding Horror: What's In a Version Number, Anyway?". Retrieved 2016-11-15.
  17. ^ "PEP 440 -- Version Identification and Dependency Specification".
  18. ^ Donald E. Knuth. The future of TeX and METAFONT, NTG journal MAPS (1990), 489. Reprinted as chapter 30 of Digital Typography, p. 571.
  19. ^ "Apple Releases macOS 10.13.3 Supplemental Update With Telugu Crash Fix". Retrieved 2018-03-26.
  20. ^ Gallagher, William (22 June 2020). "Apple turns macOS up to 11 - or to 10.16". AppleInsider.
  21. ^ Heater, Brian. "Apple unveils macOS 11.0 Big Sur". TechCrunch. Archived from the original on June 22, 2020. Retrieved June 22, 2020.
  22. ^ "Announcing Windows 10".
  23. ^ "Debian FAQ: 6.2.2 Where do these codenames come from?". Archived from the original on 2 January 2021. Retrieved 2 January 2021.
  24. ^ "BLAG Linux And GNU". DistroWatch.com. Retrieved 29 September 2011.
  25. ^ "News and Updates: BLAG". DistroWatch.com. Retrieved 29 September 2011.
  26. ^ "blag download". blag. Retrieved 29 September 2011.
  27. ^ "Kelvin Versioning · jtobin.io". jtobin.io. Retrieved 2021-03-17.
  28. ^ urbit.org. "Toward a Frozen Operating System - Urbit". urbit.org. Retrieved 2021-03-17.
  29. ^ a b "ToaruOS 1.0 Open Source OS Released After 6+ Years Of Development". February 13, 2017. Retrieved 23 May 2017.
  30. ^ a b Gilbertson, Scott. "Wine Headed For a 1.0 Release. Finally". Wired. Retrieved 23 May 2017.
  31. ^ "Firefox Release Calendar - MozillaWiki". wiki.mozilla.org.
  32. ^ "Simultaneous Release - Eclipsepedia". wiki.eclipse.org.
  33. ^ "ReleasePlan - The Document Foundation Wiki". wiki.documentfoundation.org.
  34. ^ "Releases - Ubuntu Wiki". wiki.ubuntu.com.
  35. ^ "Releases - Fedora Project Wiki". fedoraproject.org.
  36. ^ "PEP 0 -- Index of Python Enhancement Proposals (PEPs)". Python.org.
  37. ^ "Release Plan". digikam.org. March 25, 2018.
  38. ^ "VMware Product Release Tracker (vTracker)". Virten.net. February 13, 2015.
  39. ^ "Node.js is SemVer". The NodeSource Blog - Node.js Tutorials, Guides, and Updates. 2015-09-15. introduced Node with a Linux kernel-style odd/even versioning scheme. Retrieved 2018-03-26.
  40. ^ Torvalds, Linus: Notes for linux release 0.01 kernel.org, 1991.
  41. ^ Calore, Michael (August 25, 2009). "Aug. 25, 1991: Kid From Helsinki Foments Linux Revolution". WIRED. Retrieved 8 February 2018.
  42. ^ Still, Michael; Smith, Stewart (December 15, 2007). Practical MythTV: Building a PVR and Media Center PC. New York: Springer-Verlag New York, Inc. p. 9. ISBN 978-1-59059-779-8. Retrieved 15 April 2018.
  43. ^ "Slackware FAQ".
  44. ^ Kevin P. Fleming (July 21, 2011). "The Evolution of Asterisk (or: How We Arrived at Asterisk 10) | Inside the Asterisk". Digium, Inc. Retrieved 2014-05-25.
  45. ^ Paul Thurrott (2009-05-14). "Office 2010 FAQ". Archived from the original on 2009-04-19. Retrieved 2009-12-30.
  46. ^ Microsoft Visual Studio#History
  47. ^ Finnie, Ryan (2010-10-23). "I'm sorry". Retrieved 2012-02-09.

External links[edit]

  • 3 Effective Techniques For Software Versioning
  • Software Release Practice Howto
  • Software version numbering
  • Document Foundation release plan for LibreOffice, showing release trains