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

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

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

Схемы

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

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

Номер версии

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

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

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

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

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

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

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

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

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

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

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

В некоторых проектах номер основной версии используется для обозначения несовместимых выпусков. Два примера: Портативная среда выполнения Apache (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] В этой схеме версии помечены тире и некоторыми буквенно-цифровыми символами для обозначения статуса.
  • Числовой статус - это схема, в которой числа используются для обозначения статуса, как если бы он был частью последовательности. Типичный выбор - третья позиция для четырехпозиционного управления версиями.
  • Числовой 90+ это еще одна схема, в которой используются числа, но, очевидно, под номером предыдущей версии. В последней позиции используется большое число, обычно 90 или больше. Это обычно используется более старыми проектами с открытым исходным кодом, такими как ГНОМ и 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

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

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

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

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

Сброс

В некоторых случаях разработчики могут решить сбросить основной номер версии. Иногда это используется для обозначения выпуска новой фазы разработки. Например, Шахтерское ремесло Альфа-версия работала с версии 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. Некоторые компании также включают дату сборки. Номера версий могут также включать буквы и другие символы, например Лотос 1-2-3 Выпуск 1а.

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

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

Дата выпуска

Уличный боец ​​EX заставка показывая номер выпуска в CalVer формат

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

Ubuntu Linux это один из примеров проекта, использующего управление версиями календаря; Ubuntu 18.04, например, был выпущен в апреле 2018 года. Его преимущество заключается в том, что его легко связать с графиками разработки и сроками поддержки. Некоторые видеоигры также используют дату для управления версиями, например аркадная игра Уличный боец ​​EX. При запуске он отображает номер версии в виде даты и кода региона, например 961219 АЗИЯ.[нужна цитата ]

При использовании дат в управлении версиями, например, в именах файлов, обычно используется ISO 8601 схема:[15] ГГГГ-ММ-ДД, так как это легко отсортированная строка в порядке возрастания / убывания. Иногда дефисы опускаются. В Вино ранее в проекте использовалась схема управления версиями по дате, в которой использовался год, за которым следует месяц, за которым следует день выпуска; например, «Вино 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

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

TeX

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

Аналогичным образом номер версии МЕТАФОНТ асимптотически приближается е.

яблоко

В эпоху классическая Mac OS, второстепенные номера версий редко выходят за пределы ".1". Когда они это делали, они обычно прыгали прямо до «0,5», предполагая, что выпуск был «более значительным».[а] Таким образом, «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]

Майкрософт Виндоус

В Майкрософт Виндоус операционная система была сначала помечена стандартными номерами версий для 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) и Виндоус виста (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]


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

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

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

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

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

Cisco IOS программная платформа использовала расписание движения поездов с множеством отдельных поездов в течение многих лет. В последнее время появился ряд других платформ, включая Fire Fox и Fenix ​​для Android,[29] Затмение,[30] LibreOffice,[31] Ubuntu[32], Fedora[33], Python[34], digiKam[35] и VMware[36] приняли модель поезда выпуска.

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой пример не отставать от конкурентов - это когда Slackware Linux перешел с версии 4 на версию 7 в 1999 году.[41]

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

Солнце Ява время от времени была гибридная система, где внутренний номер версии всегда был 1.Икс но был продан только со ссылкой на Икс:

  • 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).

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

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

Суеверие

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

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

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

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

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

В некоторых случаях используется прямая аналогия (например: Чудаки 2.5, версия Jackass Number Two с дополнительными особенностями; второй альбом Мусор под названием Версия 2.0; или же Подземелья и Драконы 3.5, где правила были переработаны по сравнению с третьей редакцией, но не настолько, чтобы считаться четвертой).

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

Phish 1.0, 2.0, 3.0 и, возможно, 4.0 после принудительного перерыва в работе Covid 19.

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

Примечания

  1. ^ Полная последовательность классических версий 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.

Рекомендации

  1. ^ а б c d е ж грамм Престон-Вернер, Том (2013).Семантическое управление версиями 2.0.0. Creative Commons. Получено с https://semver.org/spec/v2.0.0.html.
  2. ^ Лам, Патрик; Дитрих, Йенс; Пирс, Дэвид Дж. (2020-08-16). «Включение семантики в семантическое версионирование». arXiv: 2008.07069 [cs].
  3. ^ «Управление версиями интерфейса библиотеки в Solaris и Linux».
  4. ^ «Система управления версиями Libtool». Документация по Libtool.
  5. ^ «Концепции нумерации версий - проект переносимой среды выполнения Apache». Получено 2009-04-11.
  6. ^ «Демонит: наука о нумерации версий». 2004-09-14. Получено 2009-04-11.
  7. ^ Фрэнк Кайн, Берт де Бир, Луис Мартинес, Харриет Моррил, Миха Петрич, Дэвид Вигерс, Сьюзи Вендлер.«Лучшие практики System z Parallel Sysplex».2011.p. 6.
  8. ^ "Журналы изменений Opera для Windows". Программное обеспечение Opera. 2014. Получено 6 ноября, 2014.
  9. ^ "Дома". Wiki документации по подвижному типу. 25 июня 2013 г.. Получено 6 ноября, 2014.
  10. ^ «Стандарты кодирования GNU: выпуски». Проект GNU. 2014-05-13. Получено 2014-05-25. Вы должны идентифицировать каждый выпуск с помощью пары номеров версий: основной и дополнительной. Мы не возражаем против использования более двух чисел, но маловероятно, что они вам действительно понадобятся.
  11. ^ а б "Advogato: Безумие нумерации версий". 2000-02-28. Получено 2009-04-11.
  12. ^ Руководство по политике Debian, 5.6.12 Версия
  13. ^ «История версий Java Edition». Официальная Minecraft Wiki. Получено 2019-03-06.
  14. ^ "Управление версиями календаря - CalVer". calver.org. Получено 2019-10-10.
  15. ^ Маркус Кун (2004-12-19). «Международные стандартные обозначения даты и времени». Кембриджский университет. Получено 2009-04-11.
  16. ^ Джефф Этвуд (15 февраля 2007 г.). «Coding Horror: а что в номере версии?». Получено 2016-11-15.
  17. ^ «PEP 440 - Идентификация версии и спецификация зависимостей».
  18. ^ Дональд Э. Кнут. Будущее TeX и METAFONT, NTG journal MAPS (1990), 489. Перепечатано как глава 30 Цифровая типографика, п. 571.
  19. ^ «Apple выпускает дополнительное обновление для macOS 10.13.3 с исправлением сбоев на телугу». Получено 2018-03-26.
  20. ^ Галлахер, Уильям (22 июня 2020 г.). «Apple превращает macOS до 11 - или до 10,16». AppleInsider.
  21. ^ {{cite news | last1 = Heater | first1 = Brian | title = Apple представляет macOS 11.0 Big Sur | url =https://techcrunch.com/2020/06/22/apple-unveils-macos-10-16-big-sur/%7Cwebsite=TechCrunch%7Caccess-date=June 22, 2020 | archive-url =https://web.archive.org/web/20200622183548/https://techcrunch.com/2020/06/22/apple-unveils-macos-10-16-big-sur/%7Carchive-date=June 22, 2020 | url-status = live
  22. ^ «Анонс Windows 10».
  23. ^ «Debian FAQ: 6.2.2 Откуда взялись эти кодовые имена?». Получено 15 апреля 2015.
  24. ^ "BLAG Linux и GNU". DistroWatch.com. Получено 29 сентября 2011.
  25. ^ "Новости и обновления: BLAG". DistroWatch.com. Получено 29 сентября 2011.
  26. ^ "бэг скачать". бред. Получено 29 сентября 2011.
  27. ^ а б «ОС ToaruOS 1.0 с открытым исходным кодом выпущена после более чем 6 лет разработки». 13 февраля 2017 г.. Получено 23 мая 2017.
  28. ^ а б Гилбертсон, Скотт. "Wine готовится к выпуску 1.0. Наконец-то". Проводной. Получено 23 мая 2017.
  29. ^ «Календарь выпусков Firefox - MozillaWiki». wiki.mozilla.org.
  30. ^ «Одновременный выпуск - Эклипсепедия». wiki.eclipse.org.
  31. ^ "ReleasePlan - вики-сайт Document Foundation". wiki.documentfoundation.org.
  32. ^ «Релизы - Ubuntu Wiki». wiki.ubuntu.com.
  33. ^ «Релизы - Проект Fedora Wiki». fedoraproject.org.
  34. ^ «PEP 0 - Указатель предложений по усовершенствованию Python (PEP)». Python.org.
  35. ^ «План выпуска». digikam.org. 25 марта 2018 г.
  36. ^ "VMware Product Release Tracker (vTracker)". Virten.net. 13 февраля 2015 года.
  37. ^ "Node.js - это SemVer". Блог NodeSource - Учебники, руководства и обновления по Node.js. 2015-09-15. представил Node с нечетной / четной схемой управления версиями в стиле ядра Linux. Получено 2018-03-26.
  38. ^ Торвальдс, Линус: Примечания для Linux версии 0.01 kernel.org, 1991.
  39. ^ Калор, Майкл (25 августа 2009 г.). "25 августа 1991: Парень из Хельсинки разжигает Linux-революцию". ПРОВОДНОЙ. Получено 8 февраля 2018.
  40. ^ Тем не менее, Майкл; Смит, Стюарт (15 декабря 2007 г.). Практический MythTV: Создание PVR и ПК с медиацентром. Нью-Йорк: Springer-Verlag New York, Inc., стр. 9. ISBN  978-1-59059-779-8. Получено 15 апреля 2018.
  41. ^ «Часто задаваемые вопросы по Slackware».
  42. ^ Кевин П. Флеминг (21 июля 2011 г.). «Эволюция Asterisk (или: Как мы пришли к Asterisk 10) | Внутри Asterisk». Digium, Inc. Получено 2014-05-25.
  43. ^ Пол Турротт (14 мая 2009 г.). «Часто задаваемые вопросы по Office 2010». Архивировано из оригинал на 2009-04-19. Получено 2009-12-30.
  44. ^ Microsoft Visual Studio # История
  45. ^ Финни, Райан (2010-10-23). "Мне жаль". Получено 2012-02-09.

внешняя ссылка