Версия сборки и версия файла разница

Обновлено: 06.07.2024

Критические изменения

Номера версий

Версия пакета NuGet

Идентификатор пакета NuGet в сочетании с версией пакета NuGet используется для идентификации пакета в NuGet. Например, Newtonsoft.Json + 11.0.2 . Пакет с суффиксом обозначает пакет предварительной версии, и для него используются специальные правила, благодаря которым он идеально подходит для тестирования. См. с сведения о пакетах предварительной версии.

Так как версия пакета NuGet встречается разработчикам чаще всего, мы рекомендуем обновлять ее с использованием Семантического версионирования (SemVer). SemVer указывает на значимость изменений, реализованных в очередном выпуске, помогая разработчикам правильно выбрать версию для использования. Например, переход от версии 1.0 к 2.0 указывает на наличие потенциальных критических изменений.

✔ РЕКОМЕНДУЕТСЯ использовать SemVer 2.0.0 для управления версиями пакета NuGet.

✔️ СЛЕДУЕТ использовать версию пакета NuGet в общедоступной документации, так как именно этот номер версии пользователи будут видеть чаще всего.

✔️ СЛЕДУЕТ добавить суффикс предварительной версии при выпуске нестабильной версии пакета.

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

Версия сборки

Версия сборки используется средой CLR во время выполнения для выбора загружаемой версии сборки. Выбор сборки через систему управления версиями применяется только к сборкам со строгими именами.

✔ РЕКОМЕНДУЕТСЯ указывать в AssemblyVersion только основной номер версии.

Например, для библиотек версий 1.0 и 1.0.1 можно указать одинаковое значение AssemblyVersion 1.0.0.0 , а для библиотеки 2.0 изменить AssemblyVersion на 2.0.0.0 . Если версия сборки меняется редко, потребуется меньше переадресаций привязок.

✔ РЕКОМЕНДУЕТСЯ синхронизировать основной номер версии AssemblyVersion и версию пакета NuGet.

❌ НЕ СЛЕДУЕТ использовать фиксированное значение AssemblyVersion.

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

Версия файла сборки

Версия файла сборки используется для отображения версии файла в ОС Windows и никак не влияет на поведение во время выполнения. Настройка этой версии является необязательной. Она отображается в диалоговом окне "Свойства файла" в проводнике Windows:

✔ РЕКОМЕНДУЕТСЯ использовать номер сборки непрерывной интеграции в качестве номера редакции AssemblyFileVersion.

Например, если вы создаете версию проекта 1.0.0, а номер сборки непрерывной интеграции имеет значение 99, параметр AssemblyFileVersion получит значение 1.0.0.99.

✔️️ СЛЕДУЕТ использовать формат Major.Minor.Build.Revision для версии файла.

Информационная версия сборки

Информационная версия сборки используется для сохранения дополнительных сведений о версии и никак не влияет на поведение во время выполнения. Настройка этой версии является необязательной. Если вы используете SourceLink, это значение при сборке составляется из номера версии пакета NuGet и номера в системе управления версиями. Например, 1.0.0-beta1+204ff0a включает хэш фиксации для исходного кода, из которого построена сборка. Дополнительные сведения см. в разделе Ссылка на источник.

В более ранних версиях Visual Studio отображается предупреждение сборки, если эта версия не соответствует формату Major.Minor.Build.Revision . Его можно игнорировать.

❌ НЕЖЕЛАТЕЛЬНО самостоятельно указывать информационную версию сборки.

Разрешите SourceLink автоматически создавать этот номер версии из метаданных NuGet и системы управления версиями.

Я нашел эту статью базы знаний Майкрософт поддержки (КБ), которая предоставила некоторую помощь: как использовать версию сборки и версию файла сборки.

в сценарии, где у меня есть несколько файловых сборок (т. е. 1 exe и 5 DLL), я буду использовать другую версию файла для каждого, но ту же версию сборки для всех из них, что позволяет вам знать, какой exe каждый из DLL идти с.

в решениях с несколькими проектами одна вещь, которую я нашел очень полезной, - это то, что все файлы AssemblyInfo указывают на один проект, который управляет версиями. Так что мой AssemblyInfos есть строка:

у меня есть проект с единственным файлом, который объявляет строку:

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

Я только измените основной номер сборки, когда featureset резко изменится.

Я вообще не меняю версию файла.

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

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

Не совсем. Версия файла также важна для установщика Windows при обновлении существующей версии по сравнению с предыдущей.

С моим текущим приложением каждый проект VS имеет ссылку на исходный файл "AssemblyBuildInfo", который имеет следующие атрибуты:

таким образом, все сборки в моем решении используют одну и ту же версию и информацию о компании (то есть, если мне нужно ее изменить, я изменяю ее только один раз). Исключая FileVersion, он автоматически устанавливается в AssemblyVersion.

@Adam: вы меняете версию файла с каждой сборкой? Вы используете контроль версий (SYN или VSS) и используете эту информацию для связи источника с двоичными файлами?

кажется, имеет смысл, что версия сборки остается прежней. т. е. "2.0.0.0". Это соответствует развертыванию продукта.

версия файла изменяется в соответствии с редакцией из системы управления версиями. "2.0. редакция " это предоставит ссылку из определенной dll (или exe) на источник, который построил его.

TLB, сгенерированный для COM, регистрируется как версия, состоящая из первых двух цифр "версии сборки". Например, версия сборки 1.2.5.7 становится версией 1.2 TLB. Это очень неудобно, потому что иногда я хотел бы изменить вторую цифру без необходимости перекомпилировать приложение vb6, но кажется, что мне нужно перекомпилировать, когда TLB изменения в версии.

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

Это работает, как и ожидалось (т. е. это просто работает) с приложением .NET, но не так с vb6 one. Если какая-либо из третьих цифр отличается (например, сборка версии 1.0.0.0 / файл версии 1.0.2.0), каждый раз, когда я пытаюсь создать новый объект, я получаю "ошибка автоматизации -2147024894 (0x80070002)".

Может ли кто-нибудь скажите мне, почему это происходит,и есть ли обходной путь?

Edit (2010-09-14): Как ни странно, если я компилирую с ассемблером версии 1.0.0.0, то я получил "ошибку автоматизации", даже если я перекомпилирую проект vb6.

Edit (2010-09-14, снова): после проверки с помощью ProcMon и FileMon, похоже, нет никакого доступа к файлам в оскорбительный код, только запросы реестра, большинство из которых относятся к другим версиям DLL. Похоже, что он пробует все предыдущие версии от 1.0.0.0 (которая является самой новой) до 1.0.1.3, но не следующую (1.0.2.0). Версия файла, прямо сейчас, 1.0.2.1, и это работает, если я установлю версию сборки 1.0.2.1, перекомпилирую и зарегистрирую ее.

Редактирование (2010-09-15): Есть три ошибки PATH_NOT_FOUND при поиске версии 1.0.1.3 моей .Объем библиотеки DLL в GAC (в c:windowsassemblyGAC_32, c:windowsassemblyGAC_MSIL и c:windowsassemblyGAC ) Есть некоторые другие ошибки (NAME_NOT_FOUND, в основном), но, кажется, найти все из них после попытки нескольких вариантов. Проблема, кажется, в том, что он ищет неправильную версию DLL.

Еще одно редактирование (2010-09-15, все еще): следуя совету Ханса Пассанта, я запустил оскорбительный код с fuslogvw, выполняющимся в фоновом режиме, и это важные линии, которые он бросает:

LOG: DisplayName = E_DataIndex, Version=1.0.1.3, Culture=нейтральный, PublicKeyToken=c322af271028978e (Полностью определенный)

LOG: Appbase = file:/ / / C: / Archivos de programa / Microsoft Visual Studio / VB98 /

LOG: AppName = VB6.EXE

LOG: неудачный поиск в GAC.

Edit: согласно ответу Ганса, я рано связываюсь и изменился каждый Guid интерфейса. Это, кажется, работает (да, я знаю, я должен был попробовать это раньше).

Edit (2010-09-17): я нашел причину первоначальной проблемы: я не отменял регистрацию TLB перед регистрацией нового и, поскольку я не изменял UUID, он продолжает искать последнюю установленную версию. Конечно, моя система управления версиями не самая лучшая в мире, но, зная эти подводные камни, я буду продолжать ее использовать (я довольно новичок в COM и .NET interop). Как "типы не совпадают", похоже, еще одна, не связанная с этим проблема, я удаляю информацию и, если мне не удастся решить ее самостоятельно, я открою новый вопрос.

А как насчет атрибута AssemblyInformationalVersion ?

Я нашел эту справочную статью базы знаний Майкрософт (KB), которая предоставила некоторую помощь: Как использовать версию сборки и сборку Версия файла.

В сценарии, когда у меня есть несколько файловых сборок (например, 1 exe и 5 dll), я буду использовать разные версии файлов для каждой, но одну и ту же версию сборки для всех, что позволит вам узнать, с каким exe подходит каждая из dll.

Что делать, если у вас есть несколько бывших с разными версиями сборки в зависимости от некоторых общих dll? Этот подход не является универсальным.

В решениях с несколькими проектами я нашел очень полезным то, что все файлы AssemblyInfo указывают на один проект, который управляет управлением версиями. Итак, у моего AssemblyInfos есть строка:

У меня есть проект с одним файлом, в котором объявляется строка:

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

Я меняю только основной номер сборки, когда набор функций резко меняется.

Я вообще не меняю версию файла.

В моем текущем приложении каждый проект VS имеет ссылку на исходный файл AssemblyBuildInfo, который имеет следующие атрибуты:

Таким образом, все сборки в моем решении используют одну и ту же версию и информацию о компании (то есть, если мне нужно ее изменить, я изменяю ее только один раз). Если исключить FileVersion, ему автоматически будет присвоено значение AssemblyVersion.

@Adam: Вы меняете версию файла с каждой сборкой? Используете ли вы контроль версий (SYN или VSS) и используете ли эту информацию, чтобы связать исходный код с двоичными файлами?

Кажется логичным, что версия сборки остается прежней. то есть "2.0.0.0". Это соответствует развертыванию продукта.

Версия файла изменяется, чтобы соответствовать версии из системы управления версиями. "2.0. revision" Это предоставит ссылку от конкретной dll (или exe) к источнику, который ее создал.

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

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

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

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

Методология изменения версий продукта программного обеспечения

Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.

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

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

В более поздних релизах, главное число (major) увеличивается, когда происходят значительные переходы в функциональности, второстепенное число (minor) прибавляется только тогда, когда были добавлены незначительные функции или внесены исправления. Номер версии изменяется, если исправлены все мелкие неполадки. Для типичного программного продукта используются следующие номера: 0.9 (для бета-версии), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, и т.д. Разработчики порой перескакивают от версии 5.0 сразу к 5.5, для того чтобы обозначить добавление нескольких значимых функций в программе, однако их не достаточно, чтобы изменить главный номер версии, тем не менее такие скачки все же неуместны.

Известные примеры буквенно-цифровых версий — Macromedia Flash MX, Adobe Photoshop CS2.

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

Обозначение стадии разработки

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

0 — альфа
1 — бета
2 — релиз кандидат
3 — публичный релиз

1.2.0.1 вместо 1.2-a
1.2.1.2 вместо 1.2-b2 (бета с несколькими исправленными ошибками)
1.2.2.3 вместо 1.2-rc (релиз кандидат)
1.2.3.0 вместо 1.2-r (для коммерческого распространения)
1.2.3.5 вместо 1.2-r5 (для коммерческого распространения со многими исправленными ошибками)

Разделение последовательностей

При публикации последовательности могут быть разделены знаками препинания. Выбор знаков препинания и их использования зависит от схемы.

Схема может использовать один и тот же знак препинания между последовательностями: 2.4.13, 2/4/13, 2-4-13
Выбор схемы, какие числа разделять, а какие нет, может быть противоречивым: 2.413
Схема может использовать разные знаки препинания внутри одной последовательности: 2.4_13

Номера последовательностей

Иногда в схемах существует четвертое неопубликованное число, которое обозначает сборку (build) программного обеспечения (как это делает ,Microsoft). ,Adobe Flash наоборот больше всего выделяет четвертое число версии: 10.1.53.64. Некоторые компании также включают дату сборки. Номера версий могут включать буквы и знаки препинания: Lotus 1-2-3 Release 1a.

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

Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, и т.д. Примером такого продукта может служить MediaWiki. В других программах используются десятичные номера: 1.7, 1.8, 1.81, 1.82, 1.9, и т.д. В таких программах после версии 1.8 будет идти версия 1.81, текущие релизы будут обозначаться 1.81a, 1.81b, и т.д.

Использование дат в версиях

Разработчики проекта Wine использовали даты при нумерации версий, они указывали год, месяц и день релиза: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию релизов, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например релиз апреля 2010 года пронумерован как Ubuntu 10.04. Номера сборок Microsoft Office тоже на самом деле закодированные даты.

Здесь следует отметить, что при использовании дат в нумерации версий необходимо использовать схему ISO, то есть сначала указывается год, затем месяц, а потом день (YYYY-MM-DD), причем дефис можно опускать.

Существуют также примеры нумерации версии годом выпуска (Adobe Illustrator 88, WordPerfect Office 2003). Хотя такой ход чаще всего используется в маркетинговых целях, и настоящий номер версии все равно существует. Например, версия Microsoft Windows 2000 Server на самом деле имеет номер Windows NT 5.0.

Схема нумерации версий TeX

Система TeX использует уникальную схему нумерации версий. После появления версии номер 3, ко всем последующим обновленным версиям после точки добавляли цифру, соответствующую последовательности числа Π это одна из форм унарной системы счисления – номер версии соответствует номеру цифры в числе Π. Номер последней версии 3.1415926. Такой метод отражает стабильность системы TeX. Разработчик TeX Дональд Кнут сказал, что последняя версия выйдет после его смерти и ее номер будет полное число Π, в которой все оставшиеся недочеты станут постоянными функциями. Подобной схемы придерживается METAFONT, нумеруя версии числами из математической константы e.

Схема Apple

,Apple использует формализованную структуру нумерации версий основанную на структуре NumVersion, она состоит из номера главной версии (1-2 числа), номера второстепенной версии (1 число), номера исправленной версии («bug» version) (1 число), индикатора стадии разработки (преальфа, альфа, бета и т.д.) и номера пререлиза (0-255). При написании этих номеров версий в строке, существовало условное соглашение опускать часть номера, обозначающую нулевую или последнюю стадию разработки. На пример: 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 Me (4.90), Windows XP (5.1)), после чего названия брендов (Windows Vista (6.0)). Судя по последнему релизу Windows 7, Microsoft снова вернулся к стандартной числовой схеме, хотя официальное название версии Windows 7 это 6.1.

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

Скрытые номера версий

Продукт программного обеспечения может иметь так называемый «скрытый» номер версии, который не указан в основном названии продукта (обычно в составлении скрытого номера соблюдаются все правила нумерации версий). Например, версия Java SE 5.0 имеет внутренний номер 1.5.0, а версии Windows начиная от NT 4, продолжают внутреннюю стандартную нумерацию версий: Windows 2000 это NT 5.0, XP это Windows NT 5.1, 2003 это NT 5.2, Vista это NT 6.0 и 7 это NT 6.1.

Предварительные версии продуктов программного обеспечения

Нечетные числа в обозначении версий для разработки релиза

Между сериями 1.0 и 2.6.x, Linux kernel использовал нечетную нумерацию версий, что бы обозначить релизы в разработке, а для стабильных релизов четную нумерацию. Например Linux 2.3 была серия разработок второго главного дизайна Linux kernel, а Linux 2.4 была серия стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 kernel в 2004 году, Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя четвертое при необходимости.

Apple и нечетные числа

У компании Apple были свои особенности на счет нечетных чисел, особенно во время системы MacOS. Даже тогда когда выпускались второстепенные (minor) релизы номер версии редко был больше чем 1, а если номер нужно было увеличить они перескакивали сразу на 5, предлагая при этом небольшое изменение величины между главным и второстепенным релизом (например, 8.5 значит «восемь с половиной», а 8.6 значит «восемь с половиной точка один»). Завершенная последовательность версий выглядит так: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (3.1 пропущена), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.

Версия 1.0 как ключевой этап разработки

Разработчики проприетарного программного обеспечения всегда называют первый релиз программы версия 1, а затем увеличивают номер главной версии после каждого переписывания кода. Это значит, что программа может достичь версии 3 всего за несколько месяцев разработки, при этом она еще возможно не станет стабильной и надежной.

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

Согласно этой схеме, номер версии медленно приближается к 1.0 пока устраняются все недочеты в подготовке к релизу. Разработчики MAME, например, не стремятся выпускать версию 1.0 программы эмулятора, аргументируя это тем, что она никогда не будет до конца завершена, потому что аркадные игры будут появляться всегда. За версией 0.99 просто следует версия 0.100. Подобный пример Xfire, после релиза 1.99 идет 1.100. Так за 6 лет существования eMule все еще не достигли версии 0.50.

История программ

Winamp выпустил совершенно иную конфигурацию третьей версии программы, в которой отсутствовала обратная совместимость с плагинами и другими ресурсами предыдущей версии. Однако, эта версия стала полностью совместимой с версиями 2 и 3, но нумеровалась пятой, то есть 4 была пропущена… То же самое произошло с UnixWare 7, что было соединением UnixWare 2 и Open Server 5.

Как не отставать от конкурентов

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

Это можно увидеть на примере нескольких продуктов Microsoft и America Online, а также в системе нумерации версий Sun Solaris, Java Virtual Machine, в версиях SCO Unix и Corel Word Perfect. Программные продукты filePro DB/RAD имели нумерацию от 2.0 к 3.0 к 4.0 к 4.1 к 4.5 к 4.8 к 5.0, и они уже готовят релиз 5.6, не имея при это ни одного промежуточного. Небольшую разницу можно заметить между версиями программного обеспечения AOL's PC client, хотя они нумеруют только главные релизы — 5.0, 6.0, 7.0, и т.д. Таким же образом Microsoft Access перескочили от версии 2.0 к версии 7.0, чтобы догнать нумерацию версий Microsoft Word.

У корпорации Microsoft тоже была цель догнать нумерацию версий браузера Netscape, пропустив версию 5 и выпустив сразу шестую версию Internet Explorer.

JDK 1.0.3
JDK 1.1.2 через 1.1.8
J2SE 1.2.0 («Java 2») через 1.4.2
Java 1.5.0 («Java 5»)
Java 1.6.0 («Java 6»)

Суеверия

У релиза 2007 программы Microsoft Office был внутренний номер версии 12. Релиз Office 2010 внутренне нумеровался уже 14, из-за плохой репутации чертовой дюжины.

Версия 13 WordPerfect Office программы Corel обозначена в продаже как «X3» (римская цифра 10 и «3»). Процедура повторилась в следующей версии X4.

Как преодолеть маркетинговые трудности

В середине 1990х быстро развивающиеся на китайском рынке CMMS и Maximo, перескакивали от версии Maximo Series 3 сразу к Series 5, пропуская Series 4, так как неправильное произношение номера 4 на китайском языке могло означать «смерть» или «неудача». Хотя это, однако, не остановило Maximo Series 5 при выпуске релиза 4.0. Следует отметить, что на этом нумерация Series остановилась, но возобновилась вполне успешно, начиная с релиза 1.0.

Значимость нумерации версий в разработке программного обеспечения

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

Перевод осуществлен сотрудницей компании "Chyrius" Натальей Володиной.

Читайте также: