Управление версиями программного обеспечения — это процесс присвоения уникальных имен версий или уникальных номеров версий уникальным состояниям программного обеспечения. В рамках заданной категории номеров версий (например, основной или второстепенной) эти номера обычно присваиваются в порядке возрастания и соответствуют новым разработкам в программном обеспечении. На мелкозернистом уровне контроль версий используется для отслеживания инкрементально отличающихся версий информации, независимо от того, является ли эта информация программным обеспечением, чтобы иметь возможность откатить любые изменения.
Современное компьютерное программное обеспечение часто отслеживается с использованием двух различных схем управления версиями программного обеспечения: внутреннего номера версии , который может увеличиваться много раз в течение одного дня, например, контрольного номера версии, и версии выпуска , которая обычно изменяется гораздо реже, например, семантического управления версиями [1] или кодового имени проекта.
Номера файлов использовались, в частности, в государственном управлении, а также в компаниях, для уникальной идентификации файлов или дел. Для компьютерных файлов эта практика была впервые введена в файловой системе ITS Массачусетского технологического института, позже файловой системе TENEX для PDP-10 в 1972 году. [2]
Позже были добавлены списки файлов, включая их версии, и зависимости между ними. Дистрибутивы Linux, такие как Debian, с его dpkg , на раннем этапе создали программное обеспечение для управления пакетами, которое могло разрешать зависимости между их пакетами. Первой попыткой Debian было то, что пакет знал другие пакеты, которые зависели от него. С 1994 года эта идея была перевернута, поэтому пакет знал, какие пакеты ему нужны. При установке пакета разрешение зависимостей использовалось для автоматического расчета необходимых пакетов и их установки с нужным пакетом. Для облегчения обновлений были введены минимальные версии пакетов. Таким образом, схема нумерации должна была сообщать, какая версия была новее требуемой. [3] [4] [5]
Для отслеживания различных версий программного обеспечения были созданы различные схемы нумерации версий. Повсеместность компьютеров также привела к использованию этих схем в контекстах, выходящих за рамки вычислений.
В схемах управления версиями программного обеспечения на основе последовательностей каждому выпуску программного обеспечения присваивается уникальный идентификатор, состоящий из одной или нескольких последовательностей цифр или букв. [6] Это степень общности; схемы сильно различаются в таких областях, как количество последовательностей, приписывание значения отдельным последовательностям и средства увеличения последовательностей.
В некоторых схемах идентификаторы на основе последовательностей используются для передачи значимости изменений между выпусками. Изменения классифицируются по уровню значимости, и решение о том, какую последовательность менять между выпусками, основывается на значимости изменений из предыдущего выпуска, при этом первая последовательность изменяется для наиболее значимых изменений, а изменения в последовательностях после первой представляют изменения с уменьшающейся значимостью.
В зависимости от схемы значимость может оцениваться по количеству измененных строк кода, добавленным или удаленным функциональным точкам, потенциальному влиянию на клиентов с точки зрения работы, необходимой для принятия новой версии, риску ошибок или необъявленных критических изменений, степени изменений в визуальной компоновке, количеству новых функций или почти всему, что разработчики продукта или маркетологи посчитают существенным, включая желание маркетинга подчеркнуть «относительную полезность» новой версии.
Семантическое управление версиями (также известное какSemVer)[1]— это широко распространенная схема версий[7], которая кодирует версию с помощью трехкомпонентного номера версии (Major.Minor.Patch), необязательного тега предварительной версии и необязательного метатега сборки. В этой схеме мерами значимости являются риск и функциональность. Критические изменения обозначаются увеличением основного номера (высокий риск); новые, некритические функции увеличивают вспомогательный номер (средний риск); а все остальные некритические изменения увеличивают номер патча (самый низкий риск). Наличие тега предварительной версии (-alpha, -beta) указывает на существенный риск, как и основное число, равное нулю (0.yz), которое используется для обозначения незавершенной работы, которая может содержать любой уровень потенциально критических изменений (самый высокий риск). В качестве примера вывода совместимости из версии SemVer, программное обеспечение, которое опирается на версию 2.1.5 API, совместимо с версией 2.2.3, но не обязательно с 3.2.4.
Разработчики могут выбрать переход на несколько второстепенных версий за раз, чтобы указать, что были добавлены важные функции, но этого недостаточно, чтобы оправдать увеличение номера основной версии; например, Internet Explorer 5 с 5.1 до 5.5 или Adobe Photoshop 5 до 5.5. Это может быть сделано, чтобы подчеркнуть ценность обновления для пользователя программного обеспечения или, как в случае Adobe, представить релиз на полпути между основными версиями (хотя уровни последовательного версионирования не обязательно ограничиваются одной цифрой, как в Blender версии 2.91 или Minecraft Java Edition, начиная с 1.7.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. В этой схеме распространена практика блокирования новых функций и критических изменений на этапах кандидатов на релиз, а для некоторых команд даже бета-версии блокируются только исправлениями ошибок, чтобы обеспечить конвергенцию на целевом релизе.
Другие схемы придают значение отдельным последовательностям:
Опять же, в этих примерах определение того, что представляет собой «существенное» изменение в противовес «незначительному», полностью субъективно и зависит от автора, как и то, что определяет «сборка» или чем «пересмотр» отличается от «незначительного» изменения.
Общие библиотеки в Solaris и Linux могут использовать формат current.revision.age , где: [8] [9]
Похожая проблема относительной значимости изменений и номенклатуры версий существует в книгоиздании, где номера изданий или названия могут выбираться на основе различных критериев.
В большинстве проприетарных программных продуктов первая выпущенная версия программного продукта имеет версию 1. [ необходима цитата ]
Некоторые проекты используют основной номер версии для обозначения несовместимых релизов. Два примера — Apache Portable Runtime (APR) [10] и FarCry CMS. [11]
Часто программисты пишут новое программное обеспечение, чтобы быть обратно совместимым , т. е. новое программное обеспечение разработано для корректного взаимодействия со старыми версиями программного обеспечения (используя старые протоколы и форматы файлов) и самой последней версией (используя новейшие протоколы и форматы файлов). Например, IBM z/OS разработана для корректной работы с тремя последовательными основными версиями операционной системы, работающими в одном и том же сисплексе. Это позволяет людям, которые управляют кластером компьютеров с высокой доступностью , поддерживать большую часть компьютеров в рабочем состоянии, в то время как одна машина за раз выключается, обновляется и восстанавливается для обслуживания. [12]
Часто заголовки пакетов и формат файла включают номер версии – иногда тот же, что и номер версии программного обеспечения, которое его написало; в других случаях «номер версии протокола», независимый от номера версии программного обеспечения. Код для обработки устаревших протоколов и форматов файлов часто рассматривается как мусор .
Программное обеспечение на экспериментальной стадии ( альфа или бета ) часто использует ноль в первой («основной») позиции последовательности для обозначения своего статуса. Однако эта схема полезна только для ранних стадий, а не для будущих релизов с устоявшимся программным обеспечением, где номер версии уже перешел 0. [1]
Для обозначения статуса новой версии используется ряд схем:
Две чисто числовые формы устраняют специальную логику, необходимую для обработки сравнения «альфа < бета < 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 [13] и Movable Type . [14] В десятичной схеме 1.81 является второстепенной версией, следующей за 1.8, в то время как выпуски обслуживания (т. е. только исправления ошибок) могут обозначаться буквенным суффиксом, например, 1.81a или 1.81b.
Стандартная схема нумерации версий GNU — major.minor.revision [15], но Emacs — яркий пример использования другой схемы, в которой основной номер (1) был опущен, а ревизия на сайте пользователя была добавлена, которая всегда равна нулю в исходных пакетах Emacs, но увеличена дистрибьюторами. [16] Аналогично номера пакетов Debian имеют префикс в виде необязательной «эпохи», которая используется для изменения схемы нумерации версий. [17]
В некоторых случаях разработчики могут решить сбросить основной номер версии. Иногда это используется для обозначения выпуска новой фазы разработки. Например, Minecraft Alpha работал с версии 1.0.0 до 1.2.6, а когда была выпущена Beta, она сбросила основной номер версии и работала с 1.0 до 1.8. После того, как игра была полностью выпущена, основной номер версии снова сбрасывался до 1.0.0. [18]
При печати последовательности могут быть разделены символами. Выбор символов и их использование варьируется в зависимости от схемы. В следующем списке показаны гипотетические примеры схем разделения для одного и того же выпуска (тринадцатая ревизия третьего уровня, четвертая ревизия второго уровня, вторая ревизия первого уровня): [ оригинальное исследование? ]
Когда точка используется для разделения последовательностей, она может представлять или не представлять десятичную точку — см. раздел «Увеличение последовательностей» для ознакомления с различными стилями интерпретации.
Иногда есть четвертый, неопубликованный номер, который обозначает сборку программного обеспечения (как это используется Microsoft ). Adobe Flash — яркий пример, когда публично указывается четырехчастный номер версии, например, 10.1.53.64. Некоторые компании также включают дату сборки. Номера версий могут также включать буквы и другие символы, например, Lotus 1-2-3 Release 1a.
Некоторые проекты используют отрицательные номера версий. Одним из примеров является компилятор SmartEiffel , который начинался с −1.0 и считал до 0.0. [16]
Во многих проектах используется схема управления версиями на основе даты, называемая календарным управлением версиями (также известная как CalVer [19] ).
Ubuntu — один из примеров проекта, использующего календарное управление версиями; например, Ubuntu 18.04 был выпущен в апреле 2018 года. Это имеет то преимущество, что его легко соотнести с графиками разработки и сроками поддержки. Некоторые видеоигры также используют дату в качестве управления версиями, например, аркадная игра Street Fighter EX . При запуске она отображает номер версии как дату плюс код региона, например 961219 ASIA . [ необходима цитата ]
При использовании дат в управлении версиями, например, имен файлов, обычно используют схему ISO 8601 [20] YYYY-MM-DD , так как она легко сортируется по строкам в порядке возрастания или убывания. Дефисы иногда опускаются. Проект Wine ранее использовал схему управления версиями дат, в которой использовался год, за которым следовал месяц, за которым следовал день выпуска; например, «Wine 20040505». [ необходима цитата ] В Minecraft было похожее форматирование версий, но вместо этого использовался DDHHMM, например: rd-132211, где 13 — 13 мая, а 2211 — 22:11.
Номера сборок Microsoft Office представляют собой закодированную дату: [21] первые две цифры указывают количество месяцев, прошедших с января года, в котором начался проект (при этом каждый крупный релиз Office представляет собой отдельный проект), а последние две цифры указывают день этого месяца. Таким образом, 3419 — это 19-й день 34-го месяца после января года, в котором начался проект. [ необходима цитата ]
Другие примеры, которые идентифицируют версии по году, включают Adobe Illustrator 88 и WordPerfect Office 2003. Когда год используется для обозначения версии, это обычно делается в маркетинговых целях, и фактический номер версии также существует. Например, Windows 95 имеет внутреннюю версию как MS-DOS 7.00 и Windows 4.00; аналогично, Windows 2000 имеет внутреннюю версию как NT 5.0. [22]
Python Software Foundation опубликовала документ PEP 440 – «Спецификация идентификации и зависимостей версий» [23], в котором изложена их собственная гибкая схема, определяющая сегмент эпохи, сегмент выпуска, предрелизные и пострелизные сегменты, а также сегмент выпуска в стадии разработки.
TeX имеет своеобразную систему нумерации версий, необычную функцию, изобретенную его разработчиком Дональдом Кнутом . Начиная с версии 3.1 обновления обозначаются добавлением дополнительной цифры в конце, так что номер версии асимптотически приближается к числу π . (Это форма унарной нумерации ; номер версии — это количество цифр.) По состоянию на февраль 2021 года номер версии — 3.141592653. Это отражает то, что TeX очень стабилен, и ожидаются только незначительные обновления. Разработчик TeX Дональд Кнут заявил, что «абсолютно окончательным изменением (которое будет сделано после [его] смерти)» будет изменение номера версии на π , после чего все оставшиеся ошибки станут постоянными функциями. [24]
Аналогичным образом номер версии Metafont асимптотически приближается к числу Эйлера, e . [24] По состоянию на февраль 2021 года номер версии равен 2.71828182. Metafont также был разработан Дональдом Кнутом в качестве дополнения к его системе набора TeX.
В эпоху классической Mac OS второстепенные номера версий редко выходили за пределы «.1». Когда это случалось, они обычно переходили сразу к «.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, выходящие после выпуска новой основной версии, назывались дополнительными обновлениями. [25]
Римская цифра 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, [26] была официально анонсирована как macOS 11 на WWDC в июне 2020 года и выпущена в ноябре 2020 года. [27] Следующая версия macOS, macOS Monterey , была выпущена в октябре 2021 года и увеличила свой основной номер версии до 12. [28]
Операционная система 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 [29] и последующие обновления ОС только увеличивали номер сборки и номер ревизии сборки обновления (UBR).
Преемник Windows 10, Windows 11 , был выпущен 5 октября 2021 года. Несмотря на название «11», новый выпуск Windows не увеличил свой основной номер версии до 11. Вместо этого он остался с тем же номером версии 10.0, который использовался в Windows 10. [30]
Некоторые производители программного обеспечения используют разные схемы для обозначения выпусков своего программного обеспечения. Проект Debian использует схему основных/дополнительных версий для выпусков своей операционной системы, но использует кодовые имена из фильма « История игрушек» во время разработки для обозначения стабильных, нестабильных и тестовых выпусков. [31]
BLAG Linux и GNU имеют очень большие номера версий: основные выпуски имеют такие номера, как 50000 и 60000, в то время как второстепенные выпуски увеличивают номер на 1 (например, 50001, 50002). Альфа- и бета-релизы получают десятичные номера версий, немного меньшие, чем основной номер выпуска, например, 19999.00071 для альфа 1 версии 20000 и 29999.50000 для бета 2 версии 30000. Начиная с 9001 в 2003 году, самая последняя версия по состоянию на 2011 год [обновлять]— 140000. [32] [33] [34]
Urbit использует систему версий по шкале Кельвина (названную в честь абсолютной шкалы температур Кельвина ): версии программного обеспечения начинаются с большого номера и отсчитываются до версии 0, после чего программное обеспечение считается завершенным и никакие дальнейшие изменения не вносятся. [35] [36]
Программное обеспечение может иметь «внутренний» номер версии, который отличается от номера версии, указанного в названии продукта (и который обычно более последовательно следует правилам нумерации версий). Например, 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 изначально планировалось как NT 6.4, так как самая ранняя сборка Technical Preview, предоставленная общественности, имела номер 6.4.9841. Однако это не продлилось долго, так как версия Windows 10 была быстро искусственно увеличена до 10.0 [37] для соответствия коммерческому названию, в результате чего первая выпущенная версия операционной системы получила номер 10.0.10240. Однако следует отметить, что Windows NT находится только на пятой основной ревизии, так как ее первый выпуск имел номер 3.1 (чтобы соответствовать текущему номеру выпуска Windows), а запуск Windows 10 привел к скачку версии с 6.3 до 10.0.
В сочетании с различными схемами управления версиями, перечисленными выше, обычно используется система обозначения предварительных версий, поскольку программа проходит через этапы жизненного цикла выпуска программного обеспечения .
Программы, находящиеся на ранней стадии, часто называют "альфа"-программным обеспечением, по первой букве греческого алфавита. После того, как они созреют, но еще не будут готовы к выпуску, их могут называть "бета"-программным обеспечением, по второй букве греческого алфавита. Обычно альфа-программное обеспечение тестируется только разработчиками, тогда как бета-программное обеспечение распространяется для тестирования сообществом.
Некоторые системы используют числовые версии меньше 1 (например, 0.9), чтобы обозначить свой подход к финальному релизу «1.0». Это общепринятое соглашение в программном обеспечении с открытым исходным кодом . [38] [39] Однако, если предварительная версия предназначена для существующего программного пакета (например, версии 2.5), то к номеру версии может быть добавлено «a» или «alpha». Таким образом, альфа-версия релиза 2.5 может быть идентифицирована как 2.5a или 2.5.a.
Альтернативой является обозначение предварительных версий как «кандидатов на релиз», так что программные пакеты, которые вскоре будут выпущены как определенная версия, могут иметь этот тег версии, за которым следует «rc-#», указывающий номер кандидата на релиз; при выпуске финальной версии тег «rc» удаляется.
Поезд выпуска программного обеспечения — это форма графика выпуска программного обеспечения, в котором ряд отдельных серий версий релизов программного обеспечения для нескольких продуктов выпускаются как ряд различных «поездов» по регулярному графику. Как правило, для каждой линейки продуктов в определенное время запускается ряд различных поездов выпуска, причем каждый поезд движется от первоначального выпуска к окончательной зрелости и выводу из эксплуатации по запланированному графику. Пользователи могут экспериментировать с более новым поездом выпуска, прежде чем принять его для производства, что позволяет им экспериментировать с новыми, «сырыми», релизами на ранних этапах, продолжая при этом следить за точечными релизами предыдущего поезда для своих производственных систем, прежде чем перейти к новому поезду выпуска по мере его зрелости.
Программная платформа Cisco IOS использовала график выпуска поездов со многими различными поездами в течение многих лет. Совсем недавно ряд других платформ, включая Firefox и Fenix для Android, [40] Eclipse , [41] LibreOffice , [42] Ubuntu , [43] Fedora, [44] Python, [45] digiKam [46] и VMware [47] приняли модель выпуска поездов.
Между сериями 1.0 и 2.6.x ядро 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 . [48]
Java от Sun иногда имела гибридную систему, где внутренний номер версии всегда был 1. x , но продавалась со ссылкой только на x :
Sun также отказалась от первой цифры в названии Solaris, и в маркетинговых материалах Solaris 2.8 (или 2.9) именуется Solaris 8 (или 9).
Похожий скачок произошел с конструктором АТС с открытым исходным кодом Asterisk в начале 2010-х годов, руководители проекта которого объявили, что за текущей версией 1.8.x вскоре последует версия 10. [49]
Этот подход, подвергшийся критике со стороны многих, поскольку он нарушает семантическую значимость разделов номера версии, был принят все большим числом поставщиков, включая Mozilla (для Firefox ).
Номера версий очень быстро эволюционируют от простых целых чисел (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.
Сообщества свободного программного обеспечения и открытого исходного кода, как правило, выпускают программное обеспечение рано и часто . Первоначальные версии имеют номера меньше 1, при этом версии 0.x используются для обозначения того, что программное обеспечение неполное и недостаточно надежное для общего выпуска или непригодное к использованию в его текущем состоянии. Изменения, несовместимые с предыдущими версиями, обычны для версий 0.x. Версия 1.0 используется в качестве важной вехи , указывающей на то, что программное обеспечение имеет по крайней мере все основные возможности плюс функции, которые разработчики хотели включить в эту версию, и считается достаточно надежным для общего выпуска. [38] [39] Хорошим примером этого является ядро Linux, которое было впервые выпущено как версия 0.01 в 1991 году, [50] и потребовалось время до 1994 года, чтобы достичь версии 1.0.0. [51]
Разработчики эмулятора аркадных игр MAME не собираются выпускать версию 1.0 программы, поскольку всегда будет больше аркадных игр для эмуляции, и, таким образом, проект никогда не будет по-настоящему завершен. Соответственно, за версией 0.99 последовала версия 0.100. [52]
С тех пор как Интернет стал широко распространенным, большинство поставщиков коммерческого программного обеспечения больше не следуют принципу, что основная версия должна быть «полной», и вместо этого полагаются на исправления ошибок, чтобы разобраться с известными проблемами, для которых найдено решение и которые можно исправить. [ необходима цитата ]
Довольно распространенной практикой является совершение крупных скачков в номерах версий по маркетинговым причинам. Иногда поставщики программного обеспечения просто обходят релиз 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, как и Internet Explorer от Microsoft , а также потому, что пакет приложений Mozilla унаследовал версию 5 в строке своего пользовательского агента во время разработки версии до 1.0, а Netscape 6.x был построен на базе кода Mozilla.
Другим примером того, как не отставать от конкурентов, является переход Slackware Linux с версии 4 на версию 7 в 1999 году. [53]
В середине 1990-х годов быстрорастущая CMMS , Maximo, перешла с Maximo Series 3 сразу на Series 5, пропустив Series 4 из-за предполагаемых маркетинговых трудностей этого номера на китайском рынке, где число 4 ассоциируется со «смертью» (см. тетрафобия ). Это не помешало выпустить Maximo Series 5 версии 4.0. (С тех пор версия «Series» была отменена, фактически сбросив номера версий после выпуска Series 5 версии 1.0.)
Номера версий используются потребителем или клиентом на практике для идентификации или сравнения своей копии программного продукта с другой копией, например, с новейшей версией, выпущенной разработчиком. Для программиста или компании версионирование часто используется на основе ревизии за ревизией, когда отдельные части программного обеспечения сравниваются и сопоставляются с более новыми или старыми ревизиями тех же самых частей, часто в совместной системе контроля версий .
В 21 веке все больше программистов начали использовать формализованную политику версий, такую как политика семантического версионирования. [1] Цель таких политик — облегчить другим программистам понимание того, когда изменения кода могут нарушить то, что они написали. Такие политики особенно важны для библиотек и фреймворков программного обеспечения , но также могут быть очень полезны для приложений командной строки (которые могут вызываться из других приложений) и, конечно, любых других приложений (которые могут быть написаны скриптами и/или расширены третьими лицами).
Управление версиями также является необходимой практикой для реализации многих схем исправления и обновления программного обеспечения, особенно для автоматического принятия решения о том, что и куда следует обновлять.
Номера версий позволяют людям, оказывающим поддержку, точно определить, какой код запускает пользователь, чтобы они могли исключить ошибки, которые уже были исправлены, как причину проблемы и т. п. Это особенно важно, когда у программы есть значительное сообщество пользователей, особенно когда это сообщество достаточно велико, чтобы люди, оказывающие техническую поддержку, не были людьми, которые написали код. Семантическое значение [1] нумерации стиля версия.ревизия.изменение также важно для сотрудников ИТ, которые часто используют его, чтобы определить, сколько внимания и исследований им нужно уделить новому релизу перед его развертыванием на своем объекте. Как правило, чем больше изменений, тем больше вероятность того, что что-то может сломаться (хотя изучение журнала изменений, если таковой имеется, может выявить только поверхностные или несущественные изменения). Это одна из причин некоторого отвращения, выраженного в подходе «отменить основной релиз», принятом Asterisk и другими: теперь сотрудники должны (или, по крайней мере, должны) проводить полный регрессионный тест для каждого обновления.
Некоторые файловые системы компьютеров , такие как файловая система OpenVMS , также сохраняют версии файлов. Версионирование документов относительно похоже на процедуру, используемую в компьютерах и программной инженерии, где с каждым небольшим изменением в структуре, содержании или условиях номер версии увеличивается на 1 или на меньшее или большее значение, опять же в зависимости от личных предпочтений автора и размера или важности внесенных изменений.
Номера версий программного обеспечения можно найти и на других носителях.
В некоторых случаях использование является прямой аналогией (например: Jackass 2.5 , версия Jackass Number Two с дополнительными специальными функциями; второй альбом Garbage под названием Version 2.0 ; или Dungeons & Dragons 3.5, где правила были пересмотрены по сравнению с третьим изданием, но не настолько, чтобы считаться четвертым).
Чаще всего он используется для обыгрывания ассоциации с высокими технологиями и не указывает буквально на «версию» (например, Tron 2.0 , видеоигра, являющаяся продолжением фильма Tron , или телесериал The IT Crowd , в котором второй сезон упоминается как Version 2.0). Особенно примечательным является использование Web 2.0 , относящееся к веб-сайтам начала 2000-х годов, которые делали упор на контент, создаваемый пользователями , удобство использования и совместимость .
Файлы технических чертежей и программного обеспечения САПР также могут использовать некий примитивный номер версии для отслеживания изменений.
должны идентифицировать каждый выпуск парой номеров версий, основной и дополнительной. Мы не возражаем против использования более двух номеров, но маловероятно, что они вам действительно понадобятся.