что такое версия сборки

Как лучше всего использовать версию файла и версию сборки?

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

8 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Управление версиями сборок

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

Управление версиями выполняется только для сборок со строгими именами.

Среда выполнения предпринимает несколько шагов для разрешения запроса привязки сборок.

Проверяет исходную ссылку на сборку для определения версии сборки, с которой будет связано приложение.

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

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

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

Указанные шаги показаны на следующей иллюстрации:

Дополнительные сведения о настройке приложений см. в разделе Настройка приложений. Дополнительные сведения о политике привязки см. в разделе Обнаружение сборок в среде выполнения.

Сведения о версии

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

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

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

Номер версии сборки

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

Например, в версии «1.5.1254.0» число «1» представляет основную версию, «5» — младший номер версии, «1254» — номер построения, а «0» — номер редакции.

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

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

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

Сведения о политиках привязки версий см. в разделе Настройка приложений. Дополнительные сведения о способе использования средой выполнения сведений о версии для поиска определенной сборки см. в разделе Обнаружение сборок в среде выполнения.

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

Информационная версия сборки представляет собой строку, которая добавляет к сборке дополнительные данные и служит только для информации. Она не используется на этапе выполнения. Информационная версия (в текстовом формате) соответствует описанию продукта на рынке, данным о комплектации или названии продукта. Эта версия не используется средой выполнения. Так, информационная версия может быть задана как «Среда CLR версии 1.0» или «Элемент управления NET с пакетом обновления 2». В Microsoft Windows эта информация отображается в элементе «Версия продукта» на вкладке «Версии» в диалоговом окне свойств файла.

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

Источник

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

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

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

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

Edit: извините, код ошибки был неправильным. Я не знаю, откуда взялся этот 438-й, но готов поклясться, что видел его где-то поблизости.

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, все еще): следуя совету Ханса Пассанта, я запустил оскорбительный код с 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 интерфейса. Это, кажется, работает (да, я знаю, я должен был попробовать это раньше).

Источник

Сборки имеют следующие свойства.

Сборки реализованы как файлы EXE или DLL.

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

Сведения о сборке можно получить программным путем с помощью отражения. Дополнительные сведения см. в статьях Отражение (C#) и Отражение (Visual Basic).

Сборки в среде CLR

Сборки предоставляют сведения для среды CLR, которые нужны для распознавания реализаций типов. Для среды выполнения тип не существует вне контекста сборки.

Сборка определяет следующие сведения:

Граница безопасности. Сборка представляет собой единицу, для которой запрашиваются и предоставляются разрешения. Дополнительные сведения о границах безопасности в сборках см. в разделе Вопросы безопасности сборок.

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

Граница версий. Сборка является наименьшей единицей с поддержкой версий в среде CLR. Версия для всех типов и ресурсов в одной сборке назначается как единому целому. В манифесте сборки описываются зависимости определенных версий от других сборок. Дополнительные сведения об управлении версиями см. в разделе Управление версиями сборки.

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

Единица параллельного выполнения. Дополнительные сведения о выполнении нескольких версий сборок см. в разделе Сборки и параллельное выполнение.

Создание сборки

Сборки могут быть статическими или динамическими. Статические сборки хранятся на диске в виде переносимых исполняемых (PE) файлов. Статические сборки могут включать интерфейсы, классы и ресурсы, такие как точечные рисунки, файлы JPEG и другие файлы ресурсов. Кроме того, можно создавать динамические сборки, которые запускаются непосредственно из памяти и не сохраняются на диск перед выполнением. Динамические сборки можно сохранить на диске после выполнения.

Существует несколько способов создания сборок. Можно использовать средства разработки, такие как Visual Studio, позволяющие создавать файлы DLL или EXE. Чтобы создать сборки с использованием модулей из других средств разработки, можно воспользоваться средствами из Windows SDK. Для создания динамических сборок также можно использовать интерфейсы CLR такие, как System.Reflection.Emit.

Чтобы создать сборку в Visual Studio, выберите пункт Сборка в меню Сборка.

Манифест сборки

Каждая сборка имеет файл манифеста сборки. Манифест сборки выполняет роль оглавления и содержит следующее:

Идентификатор сборки (ее имя и версию).

Таблица с описанием всех файлов, входящих в сборку. Например, сюда относятся другие ваши сборки, от которых зависит файл EXE или DLL, а также растровые изображения или файлы сведений.

Добавление ссылки на сборку

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

На C# вы можете использовать две версии одной и той же сборки в одном приложении. Дополнительные сведения см. в разделе Псевдоним extern.

Источник

Software versioning

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

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

Другой подход использования главных и второстепенных номеров версий заключается в добавлении буквенно-цифровой последовательности, определяя тем самым стадию разработки релиза: «альфа», «бета», «релиз кандидат». Серия версий с использованием этого подхода может выглядеть следующим образом: если к версиям 0.5, 0.6, 0.7, 0.8, 0.9 добавляются новые функции их можно назвать — 1.0b1, 1.0b2, еще плюс новые функции — 1.0b3, затем версия становится 1.0rc1. Если версия 1.0rc1 достаточно стабильна, то она становится 1.0, однако если в 1.0rc1 обнаруживаются ошибки, которые необходимо исправить она будет иметь номер 1.0rc2 и т.д. Важной характеристикой этого подхода является соблюдение идентичности стадий разработки версий. Нельзя вносить никаких изменений между последней бета-версией и первым релиз кандидатом или последним релиз кандидатом и готовым продуктом. Если вы это сделали, необходимо выпустить другую версию на более низкой стадии разработки.

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

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

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

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

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

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

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

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

Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 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.9, так как 1.0. это уже для публичного релиза. Однако если создается предварительная версия к уже существующему продукту, то она может быть обозначена буквой «а» (значит альфа) добавленной к номеру версии готового продукта, например версия 2.5 – предварительная версия 2.5.а или 2.5а. Продукты готовые к релизу могут быть обозначены тегом «rc-#», что означает релиз кандидат (release candidate). Когда версия уже выпущена, тег убирается.

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

Между сериями 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.

Суеверия

У релиза 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» Натальей Володиной.

Источник