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

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

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

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

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

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

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

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

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

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

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

Семантическое управление версиями (также известное как 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

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

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

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

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

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

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

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. ^ Б с д е е г Престон-Вернер, Том (2013). Семантическое управление версиями 2.0.0. Creative Commons. Получено с https://semver.org/spec/v2.0.0.html .
  2. ^ Лам, Патрик; Дитрих, Йенс; Пирс, Дэвид Дж. (2020-08-16). «Включение семантики в семантическое версионирование». arXiv : 2008.07069 [ cs.SE ].
  3. ^ «Управление версиями интерфейса библиотеки в Solaris и Linux» .
  4. ^ "Система управления версиями Libtool" . Документация по Libtool .
  5. ^ «Концепции нумерации версий - Проект переносимой среды выполнения Apache» . Проверено 11 апреля 2009 .
  6. ^ «Демонит: наука о нумерации версий» . 2004-09-14 . Проверено 11 апреля 2009 .
  7. ^ Франк Kyne, Берт де Бир, Луис Мартинес, Харриет Morril, Miha Петрик, Дэвид Viguers, Suzi Wendler. «Передовые методы работы с System z Parallel Sysplex» . 2011. с. 6.
  8. ^ «Журналы изменений Opera для Windows» . Программное обеспечение Opera . 2014 . Проверено 6 ноября 2014 года .
  9. ^ "Дом" . Wiki документации по подвижным шрифтам . 25 июня 2013 . Проверено 6 ноября 2014 года .
  10. ^ «Стандарты кодирования GNU: версии» . Проект GNU . 2014-05-13 . Проверено 25 мая 2014 . Вы должны идентифицировать каждый выпуск с помощью пары номеров версий: основной и дополнительной. Мы не возражаем против использования более двух чисел, но маловероятно, что они вам действительно понадобятся.
  11. ^ a b "Advogato: Безумие нумерации версий" . 2000-02-28 . Проверено 11 апреля 2009 .
  12. ^ Руководство по политике Debian, версия 5.6.12
  13. ^ «История версий Java Edition» . Официальная Minecraft Wiki . Проверено 6 марта 2019 .
  14. ^ "Управление версиями календаря - CalVer" . calver.org . Проверено 10 октября 2019 .
  15. ^ Маркус Кун (2004-12-19). «Международные стандартные обозначения даты и времени» . Кембриджский университет . Проверено 11 апреля 2009 .
  16. ^ Джефф Этвуд (2007-02-15). «Coding Horror: а что вообще написано в номере версии?» . Проверено 15 ноября 2016 .
  17. ^ «PEP 440 - Идентификация версии и спецификация зависимостей» .
  18. ^ Дональд Э. Кнут. Будущее TeX и METAFONT , журнал NTG MAPS (1990), 489. Перепечатано как глава 30 Digital Typography , стр. 571.
  19. ^ «Apple выпускает дополнительное обновление для macOS 10.13.3 с исправлением сбоев на телугу» . Проверено 26 марта 2018 .
  20. ↑ Галлахер, Уильям (22 июня 2020 г.). «Apple превращает macOS до 11 - или до 10,16» . AppleInsider.
  21. ↑ Нагреватель, Брайан. «Apple представляет macOS 11.0 Big Sur» . TechCrunch . Архивировано 22 июня 2020 года . Проверено 22 июня 2020 года .
  22. ^ «Анонс Windows 10» .
  23. ^ "Часто задаваемые вопросы по Debian: 6.2.2 Откуда берутся эти кодовые имена?" . Архивировано из оригинального 2 -го января 2021 года . Проверено 2 января 2021 года .
  24. ^ «BLAG Linux и GNU» . DistroWatch.com . Проверено 29 сентября 2011 года .
  25. ^ "Новости и обновления: BLAG" . DistroWatch.com . Проверено 29 сентября 2011 года .
  26. ^ "бэг скачать" . благи . Проверено 29 сентября 2011 года .
  27. ^ "Версионирование Кельвина · jtobin.io" . jtobin.io . Проверено 17 марта 2021 .
  28. ^ urbit.org. «К замороженной операционной системе - Urbit» . urbit.org . Проверено 17 марта 2021 .
  29. ^ a b «ОС ToaruOS 1.0 с открытым исходным кодом, выпущенная после более чем 6 лет разработки» . 13 февраля 2017 года . Проверено 23 мая 2017 года .
  30. ^ a b Гилбертсон, Скотт. "Wine готовится к выпуску 1.0. Наконец-то" . Проводной . Проверено 23 мая 2017 года .
  31. ^ «Календарь выпусков Firefox - MozillaWiki» . wiki.mozilla.org .
  32. ^ "Одновременный выпуск - Eclipsepedia" . wiki.eclipse.org .
  33. ^ "ReleasePlan - Документальный фонд вики" . wiki.documentfoundation.org .
  34. ^ «Релизы - Ubuntu Wiki» . wiki.ubuntu.com .
  35. ^ «Релизы - Проект Fedora Wiki» . fedoraproject.org .
  36. ^ «PEP 0 - Указатель предложений по усовершенствованию Python (PEP)» . Python.org .
  37. ^ «План выпуска» . digikam.org . 25 марта 2018 г.
  38. ^ «VMware Product Release Tracker (vTracker)» . Virten.net . 13 февраля 2015 года.
  39. ^ «Node.js - это SemVer» . NodeSource Блог - Node.js Учебники, руководства и обновления . 2015-09-15. представил Node с нечетной / четной схемой управления версиями в стиле ядра Linux . Проверено 26 марта 2018 .
  40. ^ Торвальдс, Линус: Примечания для Linux версии 0.01 kernel.org, 1991.
  41. ^ Calore, Майкл (25 августа 2009). «25 августа 1991 года: парень из Хельсинки разжигает Linux-революцию» . ПРОВОДНОЙ . Проверено 8 февраля 2018 .
  42. ^ Тем не менее, Майкл; Смит, Стюарт (15 декабря 2007 г.). Практический MythTV: Создание PVR и ПК для медиацентра . Нью-Йорк: Springer-Verlag New York, Inc., стр. 9. ISBN 978-1-59059-779-8. Проверено 15 апреля 2018 года .
  43. ^ "Часто задаваемые вопросы по Slackware" .
  44. ↑ Кевин П. Флеминг (21 июля 2011 г.). «Эволюция Asterisk (или: Как мы пришли к Asterisk 10) | Внутри Asterisk» . Digium, Inc . Проверено 25 мая 2014 .
  45. ^ Пол Турротт (2009-05-14). «Часто задаваемые вопросы по Office 2010» . Архивировано из оригинала на 2009-04-19 . Проверено 30 декабря 2009 .
  46. ^ Microsoft Visual Studio # История
  47. ^ Финни, Райан (2010-10-23). "Мне очень жаль" . Проверено 9 февраля 2012 .

Внешние ссылки [ править ]

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