Войти
Управление версиями обновления программного обеспечения - это процесс присвоения либо уникальных имен версий, либо уникальные номера версий для уникальных состояний компьютерного программного обеспечения. В рамках данной категории номера версии (основной, дополнительный) эти номера обычно присваиваются в порядке возрастания и соответствуют новым разработкам в программном обеспечении. На мелкомасштабном уровне контроль версий часто используется для отслеживания постепенно изменяющихся версий информации, независимо от того, является ли эта информация компьютерным программным обеспечением.
Современное компьютерное программное обеспечение часто отслеживается с использованием двух разных схем управления версиями программного обеспечения - внутренний номер версии, который может многократно увеличиваться в течение одного дня, например, контрольный номер версии, и версия выпуска которые обычно меняются гораздо реже, например, семантическое управление версиями или кодовое имя проекта.
Для отслеживания разных версий программного обеспечения были созданы различные схемы нумерации версий. Повсеместное распространение компьютеров также привело к тому, что эти схемы использовались вне вычислительной среды.
В схемах управления версиями программного обеспечения на основе последовательностей каждому выпуску программного обеспечения назначается уникальный идентификатор, который состоит из одной или нескольких последовательностей цифр или букв. Это степень общности; схемы широко различаются в таких областях, как количество последовательностей, приписывание значения отдельным последовательностям и способы увеличения последовательностей.
В некоторых схемах идентификаторы на основе последовательности используются для передачи значимости изменений между выпусками. Изменения классифицируются по уровню значимости, и решение о том, какую последовательность менять между выпусками, основывается на значимости изменений по сравнению с предыдущим выпуском, при этом первая последовательность изменяется для наиболее значительных изменений, а изменения в последовательностях после первого представляют. изменения уменьшающейся значимости.
В зависимости от схемы значимость может быть оценена по измененным строкам кода, добавленным или удаленным функциональным точкам, потенциальному влиянию на клиентов с точки зрения работы, необходимой для принятия новой версии, риску ошибок или необъявленных критических изменений, степень изменений визуального оформления, количество новых функций или почти все, что разработчики продукта или маркетологи считают значительными, включая маркетинговое желание подчеркнуть «относительное качество» новой версии.
Семантическое управление версиями (также известное как SemVer), в настоящее время наиболее известная и наиболее широко используемая схема версий в этой категории, использует последовательность из трех цифр (Major.Minor.Patch), дополнительный тег предварительной версии и дополнительную сборку метатег. В этой схеме мерами значимости являются риск и функциональность. Критические изменения обозначаются увеличением главного номера (высокий риск), новые неразрывные функции увеличивают второстепенное число (средний риск), а все другие неразрывные изменения увеличивают номер исправления (самый низкий риск). Наличие тега перед выпуском (-alpha, -beta) указывает на существенный риск, как и большое число, равное нулю (0.yz), которое используется для обозначения незавершенной работы, которая может содержать любой уровень потенциально критические изменения (самый высокий риск).
Разработчики могут выбрать одновременный переход к нескольким дополнительным версиям, чтобы указать, что были добавлены важные функции, но этого недостаточно, чтобы гарантировать увеличение номера основной версии; например, Internet Explorer 5 от 5.1 до 5.5 или Adobe Photoshop 5 до 5.5. Это может быть сделано для того, чтобы подчеркнуть ценность обновления для пользователя программного обеспечения или, как в случае Adobe, для представления выпуска на полпути между основными версиями (хотя уровни управления версиями на основе последовательности не ограничиваются одной цифрой, как в Blender версии 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. Обычной практикой в этой схеме является блокирование новых функций и критических изменений на этапах выпуска-кандидата, а для некоторых команд даже бета-версии привязаны только к исправлениям ошибок, чтобы обеспечить согласованность с целевым выпуском.
Другие схемы придают значение отдельным последовательностям:
Опять же, в этих примерах определение того, что составляет «основное», а не «незначительное» изменение, полностью субъективно и зависит от автора, как и то, что определяет « build », или чем« ревизия »отличается от« незначительного »изменения.
Общие библиотеки в Solaris и Linux могут использовать формат current.revision.age, где:
Аналогичная проблема относительной значимости изменений и номенклатуры управления версиями существует в книгоиздании, где номера изданий или названия могут быть выбраны на основании различных критериев.
В большинстве проприетарных программ первая выпущенная версия программного продукта имеет версию 1.
Семантическое управление версиями, состоящее из трех частей, номер версии В некоторых проектах используется основной номер версии для обозначения несовместимых выпусков. Два примера: Apache Portable Runtime (APR) и FarCry CMS.
Семантическое управление версиями - это формальное соглашение для определения совместимости с использованием номера версии из трех частей: основная версия; минорная версия; и патч. Номер патча увеличивается для незначительных изменений и исправлений ошибок, которые не изменяют интерфейс прикладного программирования (API) программного обеспечения. Дополнительная версия увеличивается для выпусков, которые добавляют новые, но обратно-совместимые функции API, а основная версия увеличивается для изменений API, которые не имеют обратной совместимости. Например, программное обеспечение, основанное на версии 2.1.5 API, совместимо с версией 2.2.3, но не обязательно с 3.2.4.
Часто программисты пишут новое программное обеспечение для обратной совместимости, т. Е. Новое программное обеспечение предназначено для правильного взаимодействия со старыми версиями программного обеспечения (с использованием старых протоколов и форматов файлов) и самыми последними версия (с использованием новейших протоколов и форматов файлов). Например, IBM z / OS предназначена для правильной работы с тремя последовательными основными версиями операционной системы, работающими в одном сисплексе. Это позволяет людям, использующим компьютерный кластер высокой доступности, поддерживать большую часть компьютеров в рабочем состоянии, пока одна машина будет выключена, обновлена и восстановлена для работы.
Часто заголовки пакетов и формат файла включают номер версии - иногда такой же, как номер версии программного обеспечения, которое его написало; в других случаях «номер версии протокола» независимо от номера версии программного обеспечения. Код для обработки старых устаревших протоколов и форматов файлов часто рассматривается как бесполезный.
Программное обеспечение на экспериментальной стадии (альфа или beta ) часто используют ноль в первой («основной») позиции последовательности для обозначения ее статуса. Однако эта схема полезна только на ранних стадиях, а не для будущих выпусков с установленным программным обеспечением, где номер версии уже превысил 0.
Для обозначения статуса более новой версии используется ряд схем:
| Stage | Semver | Num. Статус | Num 90+ |
|---|---|---|---|
| Alpha | 1.2.0-a.1 | 1.2.0.1 | 1.1.90 |
| Beta | 1.2.0-b.2 | 1.2.1.2 | 1.1.93 |
| Релиз-кандидат | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97 |
| Выпустить | 1.2.0 | 1.2.3.0 | 1.2.0 |
| Пост-релизные исправления | 1.2.5 | 1.2.3.5 | 1.2.5 |
Две чисто числовые формы устраняют особую логику, необходимую для обработки сравнения " alpha < beta < rc < no prefix" as found in semantic versioning, at the cost of clarity. (semantic versioning actually does not specify specific terms for development stages; the comparison is simply in лексикографический порядок.)
Существуют две школы мысли относительно того, как увеличиваются номера версий. Большинство бесплатных программ с открытым исходным кодом, включая 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 и т. Д. Decim все версии были распространены в 1980-х годах, например с NetWare, DOS и Microsoft Windows, но даже в 2000-х, например, использовались Opera и подвижный тип. В десятичной схеме 1.81 - это второстепенная версия, следующая за 1.8, тогда как служебные выпуски (т.е. только исправления ошибок) могут обозначаться буквенным суффиксом, например 1.81a или 1.81b.
Стандартная схема нумерации версий GNU - major.minor.revision, но Emacs является ярким примером использования другой схемы, в которой старший номер (1) был опущен и была добавлена редакция сайта пользователя, которая всегда равна нулю в исходных пакетах Emacs, но увеличена распространителями. Аналогичным образом, номера пакетов Debian имеют префикс с необязательной «эпохой», которая используется для изменения схемы управления версиями.
В некоторых случаях разработчики может решить сбросить основной номер версии. Иногда это используется для обозначения выпуска новой фазы разработки. Например, Minecraft Alpha работал с версии 1.0.0 до 1.2.6, а когда была выпущена бета-версия, он сбрасывал основной номер версии и работал с 1.0 до 1.8. После полного выпуска игры основной номер версии снова сбрасывается до 1.0.0.
При печати последовательности могут быть разделены символами. Выбор персонажей и их использование зависит от схемы. В следующем списке показаны гипотетические примеры схем разделения для одного и того же выпуска (от тринадцатой редакции третьего уровня до четвертой редакции второго уровня до второй редакции первого уровня):
Когда точка используется для разделения последовательностей, она может представлять или не представлять десятичную точку, - см. раздел «Приращение последовательностей » для различных интерпретаций стили.
Иногда существует четвертый, неопубликованный номер, который обозначает сборку программного обеспечения (как используется Microsoft ). Adobe Flash - примечательный случай, когда номер версии из четырех частей указывается публично, как в 10.1.53.64. Некоторые компании также включают дату сборки. Номера версий могут также включать буквы и другие символы, например Lotus 1-2-3 Release 1a.
В некоторых проектах используются отрицательные номера версий. Одним из примеров является компилятор SmartEiffel, который запускался с -1,0 и считался до 0,0.
Street Fighter EX экран-заставка, показывающий номер выпуска в формате CalVer Во многих проектах используется схема управления версиями на основе даты, которая называется Calendar Versioning (также известная как CalVer). Ubuntu Linux - один из примеров проекта, использующего управление версиями календаря; Например, Ubuntu 18.04 был выпущен в апреле 2018 года. Его преимущество заключается в том, что его легко связать с графиками разработки и сроками поддержки. Некоторые видеоигры также используют дату в качестве версии, например, аркадная игра Street Fighter EX. При запуске он отображает номер версии в виде даты и кода региона, например 961219 ASIA.
При использовании дат в управлении версиями, например, имен файлов, обычно используется схема ISO 8601 : ГГГГ-ММ-ДД, так как это легко отсортированная строка по возрастанию / убыванию заказ. Иногда дефисы опускаются. В проекте Wine ранее использовалась схема управления версиями по дате, в которой использовался год, за которым следует месяц, за которым следует день выпуска; например, «Вино 20040505».
Microsoft Office номера сборки представляют собой закодированную дату: первые две цифры указывают количество месяцев, прошедших с января года, в котором был запущен проект (каждый основной выпуск Office представляет собой отдельный проект), а последние две цифры указывают день этого месяца. Таким образом, 3419 - это 19-й день 34-го месяца после января года, в котором проект был запущен.
Другие примеры, которые определяют версии по годам, включают Adobe Illustrator 88 и WordPerfect Office 2003. Когда для обозначения версии используется дата, это обычно используется в маркетинговых целях, и также существует фактический номер версии. Например, Microsoft Windows 95 имеет внутреннюю версию как MS-DOS 7.00 и Windows 4.00; аналогично, Microsoft Windows 2000 Server имеет внутреннюю версию как Windows NT 5.0 («NT» - это ссылка на исходное название продукта).
Python Software Foundation опубликовал PEP 440 - Спецификация идентификации версий и зависимостей, в котором излагается собственная гибкая схема, которая определяет сегмент эпохи, сегмент релиза, сегменты до и после релиза и сегмент разработки.
TeX имеет идиосинкразическую систему нумерации версий. Начиная с версии 3, обновления обозначались добавлением дополнительной цифры в конце, так что номер версии асимптотически приближается к π ; это форма унарной нумерации - номер версии - это количество цифр. Текущая версия - 3.14159265. Это свидетельствует о том, что TeX очень стабилен, и ожидаются лишь незначительные обновления. Разработчик TeX Дональд Кнут заявил, что «абсолютно окончательное изменение (которое будет сделано после [его] смерти)» будет заключаться в изменении номера версии на π, после чего все оставшиеся ошибки станут постоянными функциями.
Подобным образом номер версии METAFONT асимптотически приближается к e.
Apple имеет формализованную структуру номера версии, основанную на структуре NumVersion, которая определяет одно- или двузначная основная версия, однозначная второстепенная версия, однозначная версия с «ошибкой» (т. е. ревизия), индикатор стадии (взятый из набора development / prealpha, alpha, beta и final / release), и однобайтовая (т.е. имеющая значения в диапазоне 0–255) предварительная версия, которая используется только на этапах, предшествующих финальной. При записи этих номеров версий в виде строк принято опускать любые части после второстепенной версии, значение которых равно нулю (при этом «final» считается нулевым этапом), таким образом записывая 1.0.2 (а не 1.0.2b12), 1.0. 2 (а не 1.0.2f0) и 1.1 (а не 1.1.0f0).
Операционная система Microsoft Windows сначала была отмечена стандартными номерами версий для Windows 1.0 - Windows 3.11. После этого Microsoft исключила номер версии из названия продукта. Для Windows 95 (версия 4.0), Windows 98 (4.10) и Windows 2000 (5.0) год выпуска был указан в названии продукта. После Windows 2000 Microsoft создала семейство Windows Server, которое продолжило стиль, основанный на годах, с той разницей: для второстепенных выпусков Microsoft добавляла суффикс «R2» к названию, например, Windows Server 2008 R2 (версия 6.1). Этот стиль сохранился до сих пор. Однако клиентские версии Windows не приняли единого стиля. Во-первых, они получили имена с произвольными буквенно-цифровыми суффиксами, например, Windows ME (4.90), Windows XP (5.1) и Windows Vista (6.0). Затем Microsoft снова ввела в заголовок инкрементные номера, но на этот раз это были не номера версий; номера версий Windows 7, Windows 8 и Windows 8.1 - соответственно 6.1, 6.2 и 6.3. В Windows 10 номер версии увеличился до 10.0, а последующие обновления ОС увеличили только номер сборки и номер версии обновления сборки (UBR).
Некоторые производители программного обеспечения используют разные схемы для обозначения выпусков своего программного обеспечения. Проект Debian использует схему управления основными / дополнительными версиями для выпусков своей операционной системы, но во время разработки использует кодовые названия из фильма История игрушек для обозначения стабильных, нестабильных и тестовых выпусков.
BLAG Linux и GNU имеет очень большие номера версий: основные выпуски имеют номера, такие как 50000 и 60000, а второстепенные выпуски увеличивают номер на 1 (например, 50001, 50002). Альфа- и бета-выпускам присваиваются десятичные номера версий, немного меньшие, чем номер основного выпуска, например, 19999.00071 для альфа-1 версии 20000 и 29999.50000 для бета-2 версии 30000. Начиная с 9001 в 2003 году, самая последняя версия по состоянию на 2011 год - 140000.
Программное обеспечение может иметь «внутренний» номер версии, который отличается от номера версии, указанного в названии продукта (и который обычно более последовательно соответствует правилам нумерации версий). Java SE 5.0, например, имеет внутренний номер версии 1.5.0, а версии Windows, начиная с NT 4 и далее, имеют внутренние числовые стандартные версии: Windows 2000 - это NT 5.0, XP - это Windows NT 5.1, Windows Server 2003 и Windows XP Professional x64 Edition - это NT 5.2, Windows Server 2008 и Vista - это NT 6.0, Windows Server 2008 R2 и Windows 7 - NT 6.1, Windows Server 2012 и Windows 8 - NT 6.2, а Windows Server 2012 R2 и Windows 8.1 - это NT 6.3, однако первая версия Windows 10 была 10.0 (10.0.10240). Обратите внимание, однако, что Windows NT находится только в пятой основной редакции, так как ее первый выпуск имел номер 3.1 (чтобы соответствовать текущему номеру выпуска Windows), а при запуске Windows 10 произошел скачок версии с 6.3 до 10.0.
В сочетании с различными схемами управления версиями, перечисленными выше, обычно используется система для обозначения предварительных версий, поскольку программа проходит через этапы Жизненный цикл выпуска программного обеспечения.
Программы, находящиеся на ранней стадии, часто называют «альфа-версиями» после первой буквы греческого алфавита. После того, как они созреют, но еще не готовы к выпуску, их можно назвать «бета-версией» после второй буквы греческого алфавита. Как правило, альфа-версия программного обеспечения тестируется только разработчиками, а бета-версия распространяется для тестирования сообществом.
Некоторые системы используют числовые версии меньше 1 (например, 0.9), чтобы предложить свой подход к окончательному выпуску "1.0". Это обычное соглашение в программном обеспечении с открытым исходным кодом. Однако, если предварительная версия предназначена для существующего программного пакета (например, версия 2.5), то к номеру версии можно добавить «а» или «альфа». Таким образом, альфа-версия выпуска 2.5 может обозначаться как 2.5a или 2.5.a.
Альтернативой является ссылка на предварительные версии как на «кандидаты на выпуск», так что программные пакеты, которые вскоре будут выпущены как конкретная версия, могут содержать этот тег версии, за которым следует «rc- #», указывающий номер релиз-кандидата; при выпуске финальной версии тег "rc" удаляется.
A Цепочка выпусков программного обеспечения - это форма графика выпуска программного обеспечения, в которой ряд отдельных серий версий программного обеспечения с установленными версиями для нескольких продуктов выпускается в виде нескольких разных «поездов» на одной регулярный график. Как правило, для каждой линейки продуктов одновременно работает несколько различных последовательностей выпуска, при этом каждая последовательность движется от начального выпуска до конечной зрелости и вывода из эксплуатации по запланированному графику. Пользователи могут поэкспериментировать с новой цепочкой выпусков, прежде чем внедрять ее в производственную среду, что позволяет им экспериментировать с более новыми, «сырыми» выпусками на ранних этапах, продолжая следовать точечным выпускам предыдущей серии для своих производственных систем до перехода. к новому шлейфу выпуска по мере его созревания.
Программная платформа Cisco IOS в течение многих лет использовала график выпуска новых поездов с множеством отдельных поездов. Совсем недавно появился ряд других платформ, включая Firefox и Fenix для Android, Eclipse, LibreOffice, Ubuntu, Fedora, Python, digiKam и VMware приняли модель поездов по выпуску.
Между сериями 1.0 и 2.6.x использовалось ядро Linux нечетные дополнительные номера версий для обозначения выпусков в стадии разработки и четные дополнительные номера версий для обозначения стабильных выпусков; см. ядро Linux § Нумерация версий. Например, Linux 2.3 был семейством разработчиков второй основной конструкции ядра Linux, а Linux 2.4 был семейством стабильных выпусков, в которое превратился Linux 2.3. После младшего номера версии в ядре Linux идет номер выпуска в возрастающем порядке; например Linux 2.4.0 → Linux 2.4.22. Начиная с выпуска ядра 2.6 в 2004 г., Linux больше не использует эту систему и имеет гораздо более короткий цикл выпуска.
Та же система нечет-четность используется некоторым другим программным обеспечением с длинными циклами выпуска, таким как Node.js до версии 0.12, а также GNOME и WineHQ.
В эпоху классической Mac OS у Apple были свои собственные изменения в этой привычке. В отличие от традиционной нумерации версий (где 1.5 не находится посередине между 1.0 и 2.0, учитывая, что может быть любое количество второстепенных выпусков, например, 1.22), классические второстепенные версии Apple Mac OS редко выходили за пределы пункта-1. Когда они это сделали, они дважды прыгнули прямо к пункту 5, предполагая, что выпуск был «более значительным». Полная последовательность классических версий Mac OS (не включая патчи): 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (пропуская 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0., 8.1, 8.5 (прыгнул), 8.6, 9.0, 9.1, 9.2. Таким образом, «8.5» стал его собственным рыночным выпуском, означающим «восемь с половиной», а 8.6 фактически - «8.5.1».
Mac OS X (переименованная в macOS ) отошла от этой тенденции в значительной степени потому, что в названии продукта стоит буква «X» (римская цифра 10). В результате все версии OS X начинаются с номера 10. Первому основному выпуску OS X был присвоен номер версии 10.0, но следующему основному выпуску был не 11.0. Вместо этого она называлась версией 10.1, за которой следовали 10.2, 10.3 и так далее для каждого последующего основного выпуска.
В этой системе третье число (вместо второго) обозначает второстепенный выпуск, а четвертое число (вместо третьего) обозначает выпуски с исправлениями ошибок / исправлениями. Поскольку первое число всегда равно 10, а последующие числа являются не десятичными, а целыми числами, 11-я основная версия OS X помечена как «10.10», а не «11.0». Несмотря на то, что в названии macOS 10.12 был исключен символ «X», эта схема нумерации продолжалась и в macOS 10.15. Следующий выпуск macOS от Apple, предварительно пронумерованный 10.16, был официально объявлен на WWDC в июне 2020 года как macOS 11.0.
Сообщества свободного программного обеспечения и открытого исходного кода имеют тенденцию выпускать программное обеспечение раньше и часто. Первоначальные версии имеют номера меньше 1, причем эти версии 0.x используются для обозначения того, что программное обеспечение является неполным и недостаточно надежным для общего выпуска или может использоваться в его текущем состоянии.
Версия 1.0 используется как основная веха, что указывает на то, что программное обеспечение имеет по крайней мере все основные функции плюс функции, которые разработчики хотели включить в эту версию, и считается достаточно надежным для общего выпуска.. Хорошим примером этого является ядро Linux, которое было впервые выпущено как версия 0.01 в 1991 году, и только в 1994 году до версии 1.0.0.
Разработчики эмулятора аркадных игр MAME никогда не намеревается выпускать версию 1.0 программы, потому что всегда будет больше аркадных игр для эмуляции, и, следовательно, проект никогда не будет полностью завершен. Соответственно, за версией 0.99 последовала версия 0.100.
Поскольку Интернет стал широко распространенным, большинство поставщиков коммерческого программного обеспечения больше не следуют этому принципу, согласно которому основная версия должна быть "полной", и вместо этого полагаются на исправления с исправлениями, позволяющими разобраться с известными проблемами, решение которых найдено и может быть исправлено.
Некоторые поставщики программного обеспечения даже заходят так далеко, что требуют применения так называемых «ежедневных исправлений», прежде чем программное обеспечение будет работать должным образом, или выпустить новые функции и функции через DLC (загружаемый контент), иногда включая базовые основные функции и функции, которые иногда можно утверждать, что они должны были быть включены в первоначальный выпуск «Версия 1.0».
Относительно распространенной практикой является резкий скачок номеров версий по маркетинговым причинам. Иногда поставщики программного обеспечения просто обходят выпуск 1.0 или быстро выпускают выпуск с последующим номером версии, потому что многие клиенты считают программное обеспечение 1.0 слишком незрелым, чтобы доверять его производственным развертываниям. Например, как и в случае с dBase II, продукт запускается с номером версии, который подразумевает, что он более зрелый, чем он есть;
В других случаях номера версий увеличиваются, чтобы соответствовать номерам конкурентов. Это можно увидеть на многих примерах нумерации версий продуктов Microsoft, America Online, Sun Solaris, Java Virtual Machine, SCO Unix, WordPerfect. Microsoft Access перешел с версии 2.0 на версию 7.0, чтобы соответствовать номеру версии Microsoft Word.
. Microsoft также стала целью «догоняющего» управления версиями с Netscape браузеры пропускают версии с 5 по 6 в соответствии с Internet Explorer от Microsoft, но также потому, что пакет приложений Mozilla унаследовал версию 5 в строке пользовательского агента во время разработки до 1.0 и Netscape 6.x был построен на базе кода Mozilla.
Еще один пример того, как не отставать от конкурентов, - это когда Slackware Linux перешел с версии 4 на версию 7 в 1999 году.
У Apple есть особенная форма пропуска номера версии, в которой используется римская цифра X в маркетинге нескольких продуктовых линеек. И QuickTime, и Final Cut Pro перешли с версии 7 непосредственно на версию 10. Как и в Mac OS X, продукты были не обновлениями до предыдущих версий, а производились под брендом. новые программы под торговыми марками QuickTime X и Final Cut Pro X, но, в отличие от настольных операционных систем Apple, не было основных версий 8 или 9. Как и в случае с OS X, однако, второстепенные выпуски обозначаются с помощью третьей цифры, а не второй цифры. Следовательно, в основных выпусках этих программ также используется вторая цифра, как это делает Apple с OS X. В WWDC 2016 они объявили, что Mac OS X была переименована в macOS.
Sun Java временами представляла собой гибридную систему, в которой внутренний номер версии всегда был 1.x, но продавался только со ссылкой на x:
Sun также опустила первую цифру для Solaris, где Solaris 2.8 (или 2.9) упоминается как Solaris 8 (или 9) в рекламных материалах.
Аналогичный скачок произошел с Asterisk конструктором PBX с открытым исходным кодом в начале 2010-х годов, руководители проекта объявили, что за текущей версией 1.8.x вскоре последует версия 10.
Этот подход, который многие осуждают из-за того, что он нарушает семантическую значимость разделов номера версии, был принят все большим числом поставщиков, включая Mozilla (для Firefox).
В середине 1990-х быстрорастущая CMMS, Maximo, напрямую перешла из Maximo Series 3 к Серии 5, пропуская Серию 4 из-за предполагаемых маркетинговых трудностей этого числа на китайском рынке, где число 4 ассоциируется со «смертью» (см. тетрафобия ). Однако это не остановило выпуск Maximo Series 5 версии 4.0. («Серийное» управление версиями с тех пор было отказано, фактически сбрасывая номера версий после выпуска Series 5 версии 1.0.)
На практике номера версий используются потребитель или клиент, чтобы идентифицировать или сравнивать свою копию программного продукта с другой копией, такой как новейшая версия, выпущенная разработчиком. Для программиста или компании управление версиями часто используется для каждой версии, когда отдельные части программного обеспечения сравниваются и противопоставляются более новым или более старым версиям тех же частей, часто в совместной системе контроля версий.
В 21 веке все больше программистов начали использовать формализованную политику версий, такую как политика семантического управления версиями. Цель таких политик - помочь другим программистам узнать, когда изменения кода могут нарушить то, что они написали. Такие политики особенно важны для программных библиотек и фреймворков, но также могут быть очень полезны для выполнения для приложений командной строки (которые могут быть вызваны из других приложений) и вообще любых других приложений. (который может быть написан и / или расширен третьими сторонами).
Управление версиями также является необходимой практикой для включения многих схем установки исправлений и обновления программного обеспечения, особенно для автоматического решения, что и где обновлять.
Номера версий позволяют людям, предоставляющим поддержку, точно определить, какой код использует пользователь, чтобы они могли исключить ошибки, которые уже были исправлены, как причину проблемы, и тому подобное. Это особенно важно, когда программа имеет значительное сообщество пользователей, особенно когда это сообщество достаточно велико, чтобы люди, обеспечивающие техническую поддержку, не были людьми, написавшими код. Семантическое значение нумерации стиля version.revision.change также важно для сотрудников информационных технологий, которые часто используют его, чтобы определить, сколько внимания и исследований им необходимо уделить новому выпуску перед его развертыванием на своем предприятии. Как показывает практика, чем больше изменения, тем выше вероятность того, что что-то может сломаться (хотя изучение журнала изменений, если таковой имеется, может выявить только поверхностные или несущественные изменения). Это один из сотрудников Причина некоторого отвращения, выраженного в подходе Asterisk et alia «отказаться от основного выпуска»: сотрудники должны (или, по крайней мере, должны) проводить полный регрессионный тест для каждого обновления.
Некоторые компьютерные файловые системы, такие как файловая система OpenVMS, также сохраняют версии для файлов.
Управление версией среди документов относительно похоже на компьютер, используемую с помощью компьютера и разработкой программного обеспечения, где с каждым небольшим изменением в структуре, содержании или номер версии увеличивается на 1 или на меньшее или большее значение, опять же, в зависимости от личных предпочтений автора и размера или важности внесенных изменений.
Номера версий очень быстроционируют от простых целых чисел (1, 2,...) до рациональных чисел (2.08, 2.09, 2.10), а и до нечисловых «», например, 4: 3.4.3-2. Поэтому эти сложные номера версий лучше рассматривать как символьные строки. Пример алгоритмы упорядочивания Red Hat и производных дистрибутивов отличаются от таковых в дистрибутивах, подобных Debian.
упорядочивание номеров версий в Debian начальные нули игнорируются в кусках, так что 5.0005 и 5.5, равными 5.5 < 5.0006. This can confuse users; string-matching tools may fail to find a given version number; and this can cause subtle bugs in package management if the programmers use string-indexed data structures such as version-number indexed hash tables.
для облегчения сортировки, некоторые программные пакеты включают каждый компонент схемы major.mi нормальный выпуск с фиксированной шириной. 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 под названием Версия 2.0 ; или Dungeons Dragons 3.5, где были правила по произволу с третьим изданием, но не настолько, чтобы считаться четвертым).
Чаще он используется, чтобы сыграть на связи с высокими технологиями, и буквально не указывает на «версию» (например, Трон 2.0, продолжение видеоигры к фильму Трон, или телесериал The IT Crowd, который относится ко второму сезону как Version 2.0). Особенно примечательным является использование Web 2.0, относящееся к веб-сайтам из начала 2000-х годов, которые подчеркивали пользовательский контент, удобство использования и <238.>совместимость.
