Управление версиями программного обеспечения
[ сломанный якорь ]
 | В этой статье может быть слишком много заголовков разделов . ( февраль 2022 г. ) |
Управление версиями программного обеспечения — это процесс присвоения уникальных имен версий или уникальных номеров версий уникальным состояниям компьютерного программного обеспечения. В пределах данной категории номеров версий (например, основных или второстепенных) эти номера обычно назначаются в порядке возрастания и соответствуют новым разработкам в программном обеспечении. На детальном уровне контроль версий используется для отслеживания постепенно различающихся версий информации, независимо от того, является ли эта информация компьютерным программным обеспечением, чтобы иметь возможность откатить любые изменения.
Современное компьютерное программное обеспечение часто отслеживается с использованием двух различных схем управления версиями программного обеспечения: внутреннего номера версии , который может увеличиваться много раз в течение одного дня, например, номера контроля версий, и версии выпуска , которая обычно меняется гораздо реже, например, семантического управления версиями. [1] или кодовое имя проекта.
История [ править ]
Номера дел использовались, в частности, в органах государственного управления, а также в компаниях, для однозначной идентификации файлов или дел. Для компьютерных файлов эта практика была впервые введена в файловой системе ITS MIT, позже файловой системе TENEX для PDP-10 в 1972 году. [2]
Позже были добавлены списки файлов, включая их версии, и зависимости между ними. Дистрибутивы Linux, такие как Debian, с его dpkg , изначально создали программное обеспечение для управления пакетами, которое могло разрешать зависимости между их пакетами. Первая попытка Debian заключалась в том, что пакет знал другие пакеты, которые от него зависели. С 1994 года эта идея была изменена: появился пакет, который знал, какие пакеты ему нужны. При установке пакета разрешение зависимостей также использовалось для автоматического расчета необходимых пакетов и их установки вместе с нужным пакетом. Для облегчения обновлений были введены минимальные версии пакета. Таким образом, схема нумерации должна была указывать, какая версия новее требуемой. [3] [4] [5]
Схемы [ править ]
Для отслеживания различных версий программного обеспечения было создано множество схем нумерации версий. Повсеместное распространение компьютеров также привело к тому, что эти схемы стали использоваться вне вычислений.
Идентификаторы на основе последовательностей [ править ]
В схемах управления версиями программного обеспечения на основе последовательностей каждому выпуску программного обеспечения присваивается уникальный идентификатор, состоящий из одной или нескольких последовательностей цифр или букв. [6] Вот степень общности; Схемы сильно различаются в таких областях, как количество последовательностей, присвоение значения отдельным последовательностям и способы увеличения последовательностей.
Изменить значение [ править ]
В некоторых схемах идентификаторы на основе последовательностей используются для передачи значимости изменений между выпусками. Изменения классифицируются по уровню значимости, и решение о том, какую последовательность изменить между выпусками, основано на значимости изменений по сравнению с предыдущим выпуском, при этом первая последовательность изменяется для наиболее значительных изменений, а изменения в последовательностях после первого представляют собой изменения уменьшающейся значимости.
В зависимости от схемы значимость может оцениваться по изменению строк кода, добавлению или удалению функциональных точек, потенциальному влиянию на клиентов с точки зрения работы, необходимой для принятия новой версии, риску появления ошибок или необъявленных критических изменений, степени изменений в визуальном интерфейсе. макет, количество новых функций или почти все, что разработчики продукта или маркетологи считают важным, включая маркетинговое желание подчеркнуть «относительное качество» новой версии.
Семантическое управление версиями
Семантическое управление версиями (также известное как SemVer ) [1] это широко распространенная схема версий [7] который кодирует версию с помощью номера версии, состоящего из трех частей (Major.Minor.Patch), необязательного тега предварительной версии и необязательного метатега сборки. В этой схеме риск и функциональность являются мерами значимости. Критические изменения обозначаются увеличением старшего числа (высокий риск); новые, неразрушающие функции увеличивают второстепенное число (средний риск); и все другие некритичные изменения увеличивают номер исправления (наименьший риск). Наличие тега предварительной версии (-альфа, -бета) указывает на существенный риск, равно как и основное число нулей (0.yz), которое используется для обозначения незавершенной работы, которая может содержать любой уровень потенциально критические изменения (наивысший риск). В качестве примера определения совместимости версии SemVer можно привести программное обеспечение, основанное на API версии 2.1.5, совместимое с версией 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. В этой схеме обычной практикой является блокировка новых функций и критических изменений на этапах кандидатов на выпуск, а для некоторых команд даже бета-версии ограничиваются только исправлениями ошибок, чтобы обеспечить конвергенцию с целевым выпуском.
Другие схемы придают значение отдельным последовательностям:
- major.minor[.build[.revision]] (пример: 1.2.12.102 )
- major.minor[.maintenance[.build]] (пример: 1.4.3.5249 )
Опять же, в этих примерах определение того, что представляет собой «существенное» изменение в отличие от «незначительного» изменения, полностью субъективно и зависит от автора, как и то, что определяет «сборку» или чем «переработка» отличается от «незначительное» изменение.
Общие библиотеки в Solaris и Linux могут использовать формат current.revision.age , где: [8] [9]
- current : Самый последний номер интерфейса, реализованный библиотекой.
- ревизия : номер реализации текущего интерфейса.
- age : разница между новейшим и старым интерфейсами, реализуемыми библиотекой. Такое использование третьего поля специфично для libtool : другие могут использовать другое значение или просто игнорировать его.
Аналогичная проблема относительной значимости изменений и номенклатуры версий существует в книжном издательстве, где номера или названия изданий могут выбираться на основе различных критериев.
В большинстве несвободных программ первая выпущенная версия программного продукта имеет версию 1. [ нужна цитата ]
Степень совместимости [ править ]
В некоторых проектах основной номер версии используется для обозначения несовместимых выпусков. Два примера: Apache Portable Runtime (APR). [10] и FarCry CMS. [11]
Часто программисты пишут новое программное обеспечение с обратной совместимостью , т. е. новое программное обеспечение предназначено для правильного взаимодействия со старыми версиями программного обеспечения (с использованием старых протоколов и форматов файлов) и самой последней версией (с использованием новейших протоколов и форматов файлов). Например, IBM z/OS спроектирована для правильной работы с тремя последовательными основными версиями операционной системы, работающими в одном и том же системном комплексе. Это позволяет людям, которые управляют компьютерным кластером высокой доступности, поддерживать работу большинства компьютеров, в то время как по одной машине выключается, обновляется и восстанавливается работоспособность. [12]
Часто заголовки пакетов и формат файла включают номер версии — иногда тот же, что и номер версии программного обеспечения, которое его написало; в других случаях «номер версии протокола» не зависит от номера версии программного обеспечения. Код для работы со старыми устаревшими протоколами и форматами файлов часто воспринимается как мусор .
Обозначение стадии разработки [ править ]
Программное обеспечение на экспериментальной стадии ( альфа или бета ) часто использует ноль в первой («основной») позиции последовательности для обозначения своего статуса. Однако эта схема полезна только на ранних этапах, а не для будущих выпусков с установленным программным обеспечением, где номер версии уже превысил 0. [1]
Для обозначения статуса новой версии используется ряд схем:
- Буквенно-цифровой суффикс — это распространенная схема, используемая при семантическом управлении версиями. [1] В этой схеме в версиях добавлено тире и несколько буквенно-цифровых символов для обозначения статуса.
- Числовой статус — это схема, в которой числа используются для обозначения статуса, как если бы он был частью последовательности. Типичным выбором является третья позиция для четырехпозиционной версии.
- Numeric 90+ — еще одна схема, в которой используются цифры, но, видимо, под номером предыдущей версии. В последней позиции используется большое число, обычно 90 или выше. Это обычно используется в старых проектах с открытым исходным кодом, таких как Fontconfig .
| Разработка этап |
Семантический управление версиями |
Числовой положение дел |
Числовой 90+ |
|---|---|---|---|
| Альфа | 1.2.0-а.1 | 1.2.0.1 | 1.1.90 |
| Бета | 1.2.0-б.2 | 1.2.1.2 | 1.1.93 |
| Кандидат на выпуск (RC) | 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 |
Две чисто числовые формы устраняют специальную логику, необходимую для обработки сравнения «альфа < бета < 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] и подвижный тип . [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, а когда была выпущена бета-версия, основной номер версии был сброшен и она работала с 1.0 до 1.8. После того, как игра была полностью выпущена, основной номер версии снова сбросился на 1.0.0. [18]
Разделение последовательностей [ править ]
При печати последовательности могут быть разделены символами. Выбор символов и их использование варьируются в зависимости от схемы. В следующем списке показаны гипотетические примеры схем разделения для одной и той же версии (от тринадцатой версии третьего уровня до четвертой версии второго уровня и второй версии первого уровня): [ оригинальное исследование? ]
- В схеме может использоваться один и тот же символ во всех последовательностях: 2.4.13, 2/4/13, 2-4-13.
- Выбор схемы того, какие последовательности следует разделить, может быть непоследовательным, разделяя одни последовательности, но не другие: 2.413
- Выбор символов в схеме может быть несовместимым в пределах одного и того же идентификатора: 2.4_13 (например, бета-версия Minecraft увеличена с 1,7 до 1.7_01 и до 1.7.2).
Когда точка используется для разделения последовательностей, она может представлять или не представлять десятичную точку — « Увеличение последовательности различные стили интерпретации см. в разделе ».
Количество последовательностей [ править ]
Иногда встречается четвертый, неопубликованный номер, обозначающий сборку программного обеспечения (используемую 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] ГГГГ-ММ-ДД , так как его легко сортировать по строкам в порядке возрастания или убывания. Дефисы иногда опускаются. В проекте 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 опубликовал PEP 440 – Спецификация идентификации версий и зависимостей. [23] излагая свою собственную гибкую схему, которая определяет сегмент эпохи, сегмент выпуска, сегменты предварительной и пост-релизной версии, а также сегмент разработки.
ТеХ [ править ]
TeX имеет своеобразную систему нумерации версий — необычную функцию, изобретенную его разработчиком Дональдом Кнутом . Начиная с версии 3.1, обновления обозначаются добавлением дополнительной цифры в конце, так что номер версии асимптотически приближается к числу π . (Это форма унарной нумерации ; номер версии представляет собой количество цифр.) По состоянию на февраль 2021 года номер версии — 3.141592653. Это отражение того, что TeX очень стабилен, и ожидаются лишь незначительные обновления. Разработчик TeX Дональд Кнут заявил, что «абсолютно окончательным изменением (который будет сделан после [его] смерти)» будет изменение номера версии на π , после чего все оставшиеся ошибки станут постоянными функциями. [24]
Аналогичным образом номер версии Метафонта асимптотически приближается к числу Эйлера, e . [24] По состоянию на февраль 2021 г. номер версии — 2.71828182. Metafont также был разработан Дональдом Кнутом в качестве дополнения к его системе набора текста TeX.
Яблоко [ править ]
В эпоху классической Mac OS второстепенные номера версий редко выходили за пределы «.1». Когда они это делали, они обычно сразу переходили к «.5», предполагая, что релиз был «более значительным». [а] Таким образом, «8.5» продавалась как отдельная версия, обозначающая «Mac OS 8 с половиной», а 8.6 фактически означала «8.5.1».
Mac OS X отошла от этой тенденции, во многом потому, что в названии продукта было «X» (римская цифра 10). В результате все версии OS X начинались с номера 10. Первому основному выпуску OS X был присвоен номер версии 10.0, но следующему основному выпуску не было 11.0. Вместо этого ему был присвоен номер 10.1, за которым следовали номера 10.2, 10.3 и так далее для каждого последующего основного выпуска. Таким образом, 11-я основная версия OS X получила обозначение «10.10». Несмотря на то, что буква «X» была исключена из названия в macOS 10.12 , эта схема нумерации сохранялась до macOS 10.15. В схеме управления версиями на основе «X» третье число (вместо второго) обозначало второстепенный выпуск и дополнительные обновления ниже этого уровня, а также обновления данной основной версии OS X, поступающие после выпуска новой версии. основная версия называлась «Дополнительные обновления». [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 стал спорным, когда в 2011 году фреймворк был признан устаревшим в пользу AVFoundation (программа для воспроизведения видео QuickTime называлась QuickTime Player только из начало).
Следующий выпуск macOS от Apple под предварительным номером 10.16 [26] была официально анонсирована как macOS 11 на WWDC в июне 2020 года и выпущена в ноябре 2020 года. [27] Следующая версия macOS, macOS Monterey , была выпущена в октябре 2021 года, и ее основной номер версии увеличился до 12. [28]
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 [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 год. [update] это 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 была 10.0 (10.0.10240). Однако обратите внимание, что Windows NT находится только на пятой основной версии, поскольку ее первый выпуск имел номер 3.1 (что соответствует текущему на тот момент номеру выпуска Windows), а при запуске Windows 10 произошел скачок версии с 6.3 до 10.0.
Предварительные версии [ править ]
В сочетании с различными схемами управления версиями, перечисленными выше, обычно используется система обозначения предварительных версий по мере прохождения программы через этапы жизненного цикла выпуска программного обеспечения .
Программы, находящиеся на ранней стадии, часто называют «альфа-программами» по первой букве греческого алфавита. После того, как они созреют, но еще не готовы к выпуску, их можно будет называть «бета-программами» по второй букве греческого алфавита. Обычно альфа-версия программного обеспечения тестируется только разработчиками, а бета-версия распространяется для тестирования сообщества.
Некоторые системы используют числовые версии меньше 1 (например, 0,9), чтобы предложить свой подход к окончательной версии «1.0». Это обычное соглашение в программном обеспечении с открытым исходным кодом . [37] [38] Однако если предварительная версия предназначена для существующего пакета программного обеспечения (например, версия 2.5), то к номеру версии может быть добавлена буква «а» или «альфа». Таким образом, альфа-версия выпуска 2.5 может обозначаться как 2.5a или 2.5.a.
Альтернативой является обращение к предварительным версиям как к «кандидатам на выпуск», чтобы пакеты программного обеспечения, которые вскоре будут выпущены как конкретная версия, могли иметь этот тег версии, за которым следует «rc-#», указывающий номер кандидата на выпуск. ; при выпуске финальной версии тег «rc» удаляется.
Выпустить поезд [ править ]
Последовательность выпусков программного обеспечения — это форма графика выпуска программного обеспечения, в которой несколько отдельных серий версий программного обеспечения для нескольких продуктов выпускаются в виде нескольких различных «потоков» по регулярному графику. Как правило, для каждой линейки продуктов в определенный момент времени выполняется несколько различных серий выпуска, при этом каждая очередь переходит от первоначального выпуска к конечному завершению и выводу из эксплуатации по запланированному графику. Пользователи могут экспериментировать с новым набором выпусков, прежде чем внедрять его в производство, что позволяет им экспериментировать с новыми, «сырыми» выпусками на ранних стадиях, продолжая при этом следовать точечным выпускам предыдущего набора для своих производственных систем перед переходом на новый выпуск, как только оно становится зрелым.
Программная платформа Cisco IOS на протяжении многих лет использовала график выпуска версий со множеством отдельных этапов. Совсем недавно ряд других платформ, включая Firefox и Fenix для Android, [39] Затмение , [40] ЛибреОфис , [41] Убунту , [42] Федора, [43] Питон, [44] дигиКам [45] и VMware [46] приняли модель выпускного поезда.
Изменения в системе счисления [ править ]
Версии с нечетными номерами для выпусков разработки [ править ]
Между сериями 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 . [47]
Удаление наиболее значимого элемента [ править ]
от Sun Java иногда имела гибридную систему, в которой внутренний номер версии всегда был 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. [48]
Этот подход, критикуемый многими, поскольку он нарушает семантическую значимость разделов номера версии, принимается все большим числом поставщиков, включая 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 как важная веха [ править ]
и Сообщества свободного программного обеспечения открытого исходного кода склонны выпускать программное обеспечение раньше и чаще . Первоначальные версии имеют номера меньше 1, при этом версия 0.x используется для обозначения того, что программное обеспечение является неполным и недостаточно надежным для общего выпуска или пригодным для использования в его текущем состоянии. Изменения, несовместимые с обратной совместимостью, часто встречаются в версиях 0.x. Версия 1.0 используется в качестве основной вехи , указывая на то, что программное обеспечение имеет по крайней мере все основные функции, а также функции, которые разработчики хотели включить в эту версию, и считается достаточно надежным для общего выпуска. [37] [38] Хорошим примером этого является ядро Linux, которое было впервые выпущено как версия 0.01 в 1991 году. [49] и потребовалось до 1994 года, чтобы достичь версии 1.0.0. [50]
Разработчики аркадных игр эмулятора MAME никогда не собираются выпускать версию 1.0 программы, поскольку всегда будет больше аркадных игр для эмуляции, и поэтому проект никогда не сможет быть по-настоящему завершен. Соответственно, за версией 0.99 последовала версия 0.100. [51]
Поскольку Интернет получил широкое распространение, большинство поставщиков коммерческого программного обеспечения больше не следуют принципу, согласно которому основная версия должна быть «полной», и вместо этого полагаются на исправления с исправлениями для устранения известных проблем, для которых было найдено решение и которые можно исправить. [ нужна цитата ]
Номера версий в качестве маркетинга [ править ]
Относительно распространенной практикой является резкое увеличение номеров версий по маркетинговым причинам. Иногда поставщики программного обеспечения просто обходят версию 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 году. [52]
Суеверие [ править ]
- Версия Microsoft Office Office 2007 имела внутренний номер версии 12. Следующая версия, Office 2010, имеет внутреннюю версию 14 из-за суеверий, связанных с числом 13 . [53] Visual Studio 2013 имеет номер версии 12.0 продукта, а новая версия Visual Studio 2015 имеет номер версии 14.0 по тем же причинам.
- Roxio Toast перешел с версии 12 на версию 14, вероятно, чтобы избежать суеверий, связанных с числом 13.
- Corel от WordPerfect Office , версия 13 продается как «X3» ( римская цифра 10 и «3»). Процедура продолжилась и в следующей версии X4. То же самое произошло с графическим пакетом Corel (например, CorelDRAW , Corel Photo-Paint ), а также с программным обеспечением для редактирования видео Video Studio.
- Sybase пропустила основные версии 13 и 14 в своем продукте реляционной базы данных Adaptive Server Enterprise, перейдя с 12.5 на 15.0.
- В словаре ABBYY Lingvo используется нумерация 12, х3 (14), х5 (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 . [54]
- Спецификация формата файла изображения с тегами использовала 42 в качестве внутреннего номера версии с момента ее создания, и ее дизайнеры не рассчитывали больше изменять его в течение своего (или его) существования, поскольку это противоречило бы директивам разработки.
маркетинговых трудностей Преодоление предполагаемых
В середине 1990-х годов быстрорастущая компания CMMS Maximo перешла с Maximo Series 3 непосредственно на Series 5, пропустив Series 4 из-за предполагаемых маркетинговых трудностей этого номера на китайском рынке, где число 4 ассоциируется со «смертью» (см. тетрафобия ). Это не помешало выпуску Maximo Series 5 версии 4.0. (С тех пор управление версиями «Series» было прекращено, что фактически привело к сбросу номеров версий после выпуска Series 5 версии 1.0.)
Значение [ править ]
В области разработки программного обеспечения [ править ]
Номера версий на практике используются потребителем или клиентом для идентификации или сравнения своей копии программного продукта с другой копией, например, с самой новой версией, выпущенной разработчиком. Для программиста или компании управление версиями часто используется для каждой ревизии, когда отдельные части программного обеспечения сравниваются и противопоставляются более новым или старым версиям тех же самых частей, часто в совместной системе контроля версий .
В 21 веке все больше программистов начали использовать формализованную политику версий, такую как политика семантического управления версиями. [1] Цель таких политик — помочь другим программистам узнать, когда изменения кода могут нарушить написанное ими. Такие политики особенно важны для программных библиотек и платформ , но также могут быть очень полезны для приложений командной строки (которые могут вызываться из других приложений), а также для любых других приложений (которые могут быть написаны скриптами и/или расширены третьими лицами). ).
Управление версиями также является необходимой практикой для реализации многих схем внесения исправлений и обновлений программного обеспечения, особенно для автоматического принятия решения о том, что и где обновлять.
В техподдержке [ править ]
определить, Номера версий позволяют людям, оказывающим поддержку, точно какой код использует пользователь, чтобы они могли исключить уже исправленные ошибки как причину проблемы и тому подобное. Это особенно важно, когда программа имеет значительное сообщество пользователей, особенно когда это сообщество достаточно велико, и люди, обеспечивающие техническую поддержку, не являются людьми, написавшими код. Семантическое значение [1] Нумерация стилей version.revision.change также важна для сотрудников информационных технологий, которые часто используют ее, чтобы определить, сколько внимания и исследований им необходимо уделить новой версии, прежде чем развернуть ее на своем предприятии. Как правило, чем больше изменений, тем выше вероятность того, что что-то может сломаться (хотя изучение журнала изменений, если таковой имеется, может выявить только поверхностные или несущественные изменения). Это одна из причин некоторого отвращения, выраженного в подходе «отказ от основной версии», принятом Asterisk и другими: теперь сотрудники должны (или, по крайней мере, должны) проводить полный регрессионный тест для каждого обновления.
Непрограммное использование [ править ]
Некоторые компьютерные файловые системы , такие как файловая система OpenVMS , также сохраняют версии файлов. Управление версиями документов относительно похоже на процедуру, используемую в компьютерах и разработке программного обеспечения, где при каждом небольшом изменении в структуре, содержании или условиях номер версии увеличивается на 1 или на меньшее или большее значение, опять же в зависимости от личных предпочтений. предпочтения автора и размер или важность внесенных изменений.
Номера версий программного обеспечения можно найти на других носителях.
В некоторых случаях использование является прямой аналогией (например: Jackass 2.5 , версия Jackass Number Two с дополнительными специальными возможностями; второй альбом Garbage под названием Version 2.0 ; или Dungeons & Dragons 3.5, где правила были пересмотрены с третье издание, но не настолько, чтобы считаться четвертым).
Чаще всего оно используется для ассоциации с высокими технологиями и не указывает буквально «версию» (например, «Трон 2.0» , видеоигра, продолжение фильма «Трон» , или телесериал «IT Crowd» , который относится к второй сезон как версия 2.0). Особенно примечательным примером использования является Web 2.0 , относящийся к веб-сайтам начала 2000-х годов, которые делали упор на пользовательский контент , удобство использования и совместимость .
Файлы технических чертежей и программного обеспечения САПР также могут использовать какой-то примитивный номер версии для отслеживания изменений.
См. также [ править ]
Примечания [ править ]
- ^ Полная последовательность классических версий 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.
Ссылки [ править ]
- ^ Перейти обратно: а б с д Это ж Престон-Вернер, Том (2013). Семантическое управление версиями 2.0.0. Креативное сообщество. Получено с https://semver.org/spec/v2.0.0.html .
- ^ TENEX, страничная система разделения времени для PDP-10 , Бобров, Берчфилд, Мерфи, Томлинсон, март 1972 г., Communications of ACM 15 (3): 135-143.
- ^ Взаимозависимости пакетов , Роберт Сандерс, 25 февраля 1994 г.
- ^ [< https://lists.debian.org/debian-devel/1995/07/msg00085.html Ошибка № 1167: пакеты разработки ELF выходят из строя или в них отсутствуют зависимости], Ян Джексон, 30 июля 1995 г.
- ^ Краткая история Debian , Хавьер Фернандес-Сангуино и др., 26 октября 2021 г.
- ^ «PEP 440 – Спецификация идентификации версии и зависимостей | peps.python.org» . peps.python.org . Проверено 19 апреля 2023 г.
- ^ Лам, Патрик; Дитрих, Йенс; Пирс, Дэвид Дж. (16 августа 2020 г.). «Введение семантики в семантическое версионирование». Материалы Международного симпозиума ACM SIGPLAN 2020 года, посвященного новым идеям, новым парадигмам и размышлениям о программировании и программном обеспечении . стр. 157–179. arXiv : 2008.07069 . дои : 10.1145/3426428.3426922 . ISBN 9781450381789 . S2CID 221139849 .
- ^ «Управление версиями библиотечного интерфейса в Solaris и Linux» .
- ^ «Система версий Libtool» . Документация по Либтулу .
- ^ «Концепции нумерации версий — проект переносимой среды выполнения Apache» . Проверено 11 апреля 2009 г.
- ^ «Daemonite: наука о нумерации версий» . 14 сентября 2004 года . Проверено 11 апреля 2009 г.
- ^ Фрэнк Кайн, Берт де Бир, Луис Мартинес, Харриет Моррил, Миха Петрич, Дэвид Вигерс, Сьюзи Вендлер. «Лучшие практики System z Parallel Sysplex» . 2011. п. 6.
- ^ «Журналы изменений Opera для Windows» . Программное обеспечение Опера . 2014 . Проверено 6 ноября 2014 г.
- ^ "Дом" . Wiki-документация Movable Type . 25 июня 2013 года . Проверено 6 ноября 2014 г.
- ^ «Стандарты кодирования GNU: выпуски» . Проект ГНУ . 13 мая 2014 года . Проверено 25 мая 2014 г.
Каждому выпуску следует идентифицировать пару номеров версий: основную и второстепенную версии. Мы не возражаем против использования более двух чисел, но маловероятно, что они вам действительно нужны.
- ^ Перейти обратно: а б «Адвогато: безумие нумерации версий» . 28 февраля 2000 года . Проверено 11 апреля 2009 г.
- ^ Руководство по политике Debian, версия 5.6.12.
- ^ «История версий Java Edition» . Майнкрафт википедия . Проверено 24 сентября 2023 г.
- ^ «Версии календаря — CalVer» . Calver.org . Проверено 10 октября 2019 г.
- ^ Маркус Кун (19 декабря 2004 г.). «Международный стандарт обозначения даты и времени» . Кембриджский университет . Проверено 11 апреля 2009 г.
- ^ Джефф Этвуд (15 февраля 2007 г.). «Ужас кодирования: что вообще такое в номере версии?» . Проверено 15 ноября 2016 г.
- ^ Пер Кристенссон (20 октября 2006 г.). «Что означает «NT» в Windows NT?» . Проверено 13 августа 2022 г.
- ^ «PEP 440 – Идентификация версии и спецификация зависимостей» .
- ^ Перейти обратно: а б Кнут, Дональд Э. (декабрь 1990 г.). «Будущее TeX и Metafont» (PDF) . БУКСИР . 11 (4): 489 . Проверено 7 сентября 2023 г.
- ^ «Apple выпускает дополнительное обновление macOS 10.13.3 с исправлением сбоев на телугу» . Проверено 26 марта 2018 г.
- ^ Галлахер, Уильям (22 июня 2020 г.). «Apple обновляет macOS до версии 11 – или до 10.16» . AppleInsider.
- ^ Хитер, Брайан. «Apple представляет macOS 11.0 Big Sur» . ТехКранч . Архивировано из оригинала 22 июня 2020 года . Проверено 22 июня 2020 г.
- ^ Де Лупер, Кристиан (12 октября 2021 г.). «Apple macOS Monterey: все, что мы знаем на данный момент» . БГР. Архивировано из оригинала 10 октября 2021 года.
- ^ «Анонс Windows 10» .
- ^ «Windows 11: сегодня начинается новая эра для ПК» . Блоги Windows . 4 октября 2021 г.
- ^ «Часто задаваемые вопросы по Debian: 6.2.2 Откуда взялись эти кодовые имена?» . Архивировано из оригинала 10 декабря 2020 года . Проверено 2 января 2021 г.
- ^ «BLAG Linux и GNU» . DistroWatch.com . Проверено 29 сентября 2011 г.
- ^ «Новости и обновления: БЛАГ» . DistroWatch.com . Проверено 29 сентября 2011 г.
- ^ "загрузка блога" . благ . Проверено 29 сентября 2011 г.
- ^ «Версии по Кельвину · jtobin.io» . jtobin.io . Проверено 17 марта 2021 г.
- ^ urbit.org. «На пути к зависшей операционной системе – Urbit» . urbit.org . Проверено 17 марта 2021 г.
- ^ Перейти обратно: а б «Операционная система с открытым исходным кодом ToaruOS 1.0 выпущена после более чем 6 лет разработки» . 13 февраля 2017 года . Проверено 23 мая 2017 г.
- ^ Перейти обратно: а б Гилбертсон, Скотт. «Wine готовится к выпуску 1.0. Наконец-то» . Проводной . Проверено 23 мая 2017 г.
- ^ «Календарь выпусков Firefox – MozillaWiki» . Wiki.mozilla.org .
- ^ «Одновременный выпуск – Эклипсепедия» . wiki.eclipse.org .
- ^ «ReleasePlan — Wiki Document Foundation» . wiki.documentfoundation.org .
- ^ «Релизы — Ubuntu Wiki» . wiki.ubuntu.com .
- ^ «Релизы — Wiki проекта Fedora» . Fedoraproject.org .
- ^ «PEP 0 — Индекс предложений по улучшению Python (PEP)» . Python.org .
- ^ «План выпуска» . digikam.org . 25 марта 2018 г.
- ^ «Отслеживание выпуска продуктов VMware (vTracker)» . Виртен.нет . 13 февраля 2015 г.
- ^ «Node.js — это SemVer» . Блог NodeSource — учебные пособия, руководства и обновления по Node.js. 15 сентября 2015 г. представлен Node со схемой нечетного/четного управления версиями в стиле ядра Linux . Проверено 26 марта 2018 г.
- ^ Кевин П. Флеминг (21 июля 2011 г.). «Эволюция Asterisk (или: Как мы пришли к Asterisk 10) | Внутри Asterisk» . Дигиум, Инк . Проверено 25 мая 2014 г.
- ^ Торвальдс, Линус: Примечания к выпуску Linux 0.01 kernel.org, 1991.
- ^ Калор, Майкл (25 августа 2009 г.). «25 августа 1991 года: Парень из Хельсинки разжигает Linux-революцию» . ПРОВОДНОЙ . Проверено 8 февраля 2018 г.
- ^ И все же, Майкл; Смит, Стюарт (15 декабря 2007 г.). Практический мифТВ: сборка ПК с PVR и медиацентром . Нью-Йорк: Springer-Verlag New York, Inc., с. 9. ISBN 978-1-59059-779-8 . Проверено 15 апреля 2018 г.
- ^ «Часто задаваемые вопросы по Slackware» .
- ^ Пол Терротт (14 мая 2009 г.). «Часто задаваемые вопросы по Office 2010» . Архивировано из оригинала 19 апреля 2009 года . Проверено 30 декабря 2009 г.
- ^ Финни, Райан (23 октября 2010 г.). "Мне жаль" . Проверено 9 февраля 2012 г.