Правильный выбор номеров версий программного обеспечения.v1.0.0.1 [закрыто]

Question

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

Давайте предположим, что A.B.C.D присутствует в ответах.Когда вы увеличиваете количество каждого из компонентов?

Используете ли вы какие-либо другие трюки с номером версии, такие как D mod 2 == 1 означает, что это только собственная версия?

Есть ли у вас бета-версии с собственными номерами версий, или у вас есть бета-версии с каждым номером версии?

Answer 1

Мне начинает нравиться год выпуска.Соглашение о выпуске [.Build], согласно которому некоторые приложения (напримерВолей-неволей) использовать.По сути, там просто указан год, в котором вы выпускаете, и последовательность действий в течение этого года.Таким образом, 2008.1 будет первой версией, и если вы выпустите другую месяцем или тремя позже, она перейдет на 2008.2.

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

Необязательным дополнением является пометка на номере сборки, но это, как правило, только для внутренних целей (напримердобавлен в EXE / DLL, чтобы вы могли проверить файл и убедиться, что там есть правильная сборка).

Answer 2

На мой взгляд, практически любую схему выпуска номеров можно заставить работать более или менее разумно.Система, над которой я работаю, использует номера версий, такие как 11.50.UC3, где U обозначает 32-разрядную версию Unix, а C3 - номер незначительной версии (пакета исправлений);другие буквы используются для других типов платформ.(Я бы не рекомендовал эту схему, но она работает.)

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

• Не выпускайте одну и ту же версию дважды - после того, как версия 1.0.0 будет выпущена для всех, она никогда не сможет быть переиздана.
• Количество выпусков должно монотонно увеличиваться.То есть код в версии 1.0.1, 1.1.0 или 2.0.0 всегда должен быть более поздним, чем версии 1.0.0, 1.0.9 или 1.4.3 (соответственно).

Теперь, на практике, людям приходится выпускать исправления для старых версий, пока доступны более новые версии - см., например, GCC:

• GCC 3.4.6 был выпущен после 4.0.0, 4.1.0 (и AFAICR 4.2.0), но он продолжает функциональность GCC 3.4.x, а не добавляет дополнительные функции, добавленные в GCC 4.x.

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

Еще один момент, в который я твердо верю:

• Номер версии выпуска не связан с нумерацией версий системы CM (VCS), за исключением тривиальных программ.Любая серьезная часть программного обеспечения с более чем одним основным исходным файлом будет иметь номер версии, не связанный с версией какого-либо отдельного файла.

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

Для материалов, с которыми я работаю, номер версии - это чисто политическое решение.

Кстати, я знаю программное обеспечение, которое выпускалось с версии 1.00 по 9.53, но затем было изменено на 2.80.Это была грубая ошибка, продиктованная маркетингом.Конечно, версия программного обеспечения 4.x устарела / была устаревшей, поэтому это не сразу привело к путанице, но версия программного обеспечения 5.x все еще используется и продается, и количество исправлений уже достигло 3.50.Я очень беспокоюсь о том, что будет делать мой код, который должен работать как с 5.x (старый стиль), так и с 5.x (новый стиль), когда возникнет неизбежный конфликт.Наверное, я должен надеяться, что они будут медлить с переходом на 5.x, пока старый 5.x действительно не умрет, но я не настроен оптимистично.Я также использую искусственный номер версии, такой как 9.60, для представления кода 3.50, чтобы я мог действовать разумно if VERSION > 900 тестирование, а не необходимость делать: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), где я представляю версию 9.00 на 900.И еще есть существенное изменение, внесенное в версию 3.00.xC3 - моей схеме не удается обнаружить изменения на уровне младшего выпуска...ворчу ... ворчу...

Примечание:Эрик Рэймонд обеспечивает Практическое руководство по выпуску программного обеспечения включая (связанный) раздел об именовании (нумерации) релизов.

Answer 3

Обычно я использую D в качестве счетчика сборки (автоматическое увеличение компилятором) Я увеличиваю C каждый раз, когда сборка выпускается "общедоступной" (не каждая сборка выпускается) A и B используются в качестве основных / второстепенных номеров версий и изменяются вручную.

Answer 4

Я думаю, что есть два способа ответить на этот вопрос, и они не совсем дополняют друг друга.

1. Технический:Увеличивайте версии в зависимости от технических заданий.Пример:D - номер сборки, C - Итерация, B - второстепенный выпуск, A - основной выпуск.Определение второстепенных и основных выпусков действительно субъективно, но может быть связано с такими вещами, как изменения в базовой архитектуре.
2. Маркетинг:Увеличивайте количество версий в зависимости от того, сколько "новых" или "полезных" функций предоставляется вашим клиентам.Вы также можете привязать номера версий к политике обновления...Изменения в A требуют от пользователя приобретения лицензии на обновление, в то время как другие изменения этого не делают.

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

Затем есть пример из Micrsoft, где единственным рациональным объяснением номеров версий .Net Framework является то, что был задействован маркетинг.

Answer 5

Наша политика:

• A - Значительные (> 25%) изменения или дополнения в функциональности или интерфейсе.
• B - небольшие изменения или дополнения в функциональности или интерфейсе.
• C - незначительные изменения, которые нарушают интерфейс.
• Исправленные исправления в сборке, которые не меняют интерфейс.

Answer 6

Люди, как правило, хотят сделать это намного сложнее, чем это должно быть на самом деле.Если ваш продукт имеет только одну долговечную ветвь, просто назовите последующие версии по номеру сборки.Если у вас есть что-то вроде "незначительные исправления ошибок бесплатны, но вы должны заплатить за основные новые версии", тогда используйте 1.0, 1.1 ...1.n, 2.0, 2.1...и т.д.

Если вы не можете сразу понять, что такое A, B, C и D в вашем примере, то они вам, очевидно, не нужны.

Answer 7

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

Мое единственное правило призвано свести к минимуму ошибки при сообщении этого числа: все четыре числа должны состоять только из 1 цифры.

1.1.2.3

это нормально, но

1.0.1.23

это не так.Клиенты, скорее всего, сообщат оба числа (по крайней мере, устно) как "один-один-два-три".

Автоматически увеличивающиеся номера сборок часто приводят к таким номерам версий, как

1.0.1.12537

что тоже на самом деле не помогает.

Answer 8

Хорошая и нетехническая схема просто использует дату сборки в этом формате:

ГГГГ.ММ.ДД.Номер здания

Где BuildNumber - это либо непрерывное число (список изменений), либо просто начинается с 1 каждый день.

Примеры:2008.03.24.1 или 2008.03.24.14503

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

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

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

Answer 9

Я использую V.R.M, например2.5.1

Изменения в V (версии) являются серьезной переработкой
Изменения R (revision) - это существенные новые функции или исправления ошибок
M (модификация) изменения - это незначительные исправления bux (опечатки и т.д.)

Иногда я также использую номер коммита SVN в конце.

Answer 10

В конце концов, все это действительно субъективно и зависит только от вас самих / вашей команды.

Просто взгляните на все ответы, которые уже есть - все они очень разные.

Лично я использую Major.Minor.*.* - Где Visual Studio автоматически заполняет номер версии / сборки.Это используется и там, где я работаю.

Answer 11

Хорошая, удобная для пользователя схема управления версиями, созданная в старой Mac OS, описана в этой технической записке Apple: http://developer.apple.com/technotes/tn/tn1132.html

Answer 12

Мне нравится год.Месяц.День. Итак, v2009.6.8 будет "версией" этого поста.Это невозможно дублировать (разумно), и очень ясно, когда что-то является более новой версией.Вы также могли бы отбросить десятичные дроби и сделать его v20090608.

Answer 13

В случае библиотеки номер версии сообщает вам о уровень совместимости между двумя выпусками и, следовательно, насколько сложным будет обновление.

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

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

Основные номера версий могут нарушать работу всех трех форм.

Я написал больше о логическом обосновании здесь.

Answer 14

В мире github стало популярным следовать спецификации Тома Престона-Вернера "semver" для номеров версий.

От http://semver.org/ :

Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:

ОСНОВНАЯ версия, когда вы вносите несовместимые изменения в API, ВТОРОСТЕПЕННАЯ версия когда вы добавляете функциональность обратно совместимым способом и ИСПРАВЛЯЕТЕ версию, когда вы исправляете обратно совместимые ошибки.Дополнительные метки для метаданных предварительного выпуска и сборки доступны в виде расширений к формату MAJOR.MINOR.PATCH.

Answer 15

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

[Program #] . [Year] . [Month] . [Release # of this app within the month]

Например, если я выпускаю приложение № 15 сегодня, и это третье обновление за месяц, то моя версия № будет

15.2008.9.3

Это совершенно нестандартно, но для нас полезно.

Answer 16

Для последних шести основных версий мы использовали M.0.m.b, где M - основная версия, m - второстепенная версия, а b - номер сборки.Таким образом, выпущенные версии включали 6.0.2, 7.0.1, ..., вплоть до 11.0.0.Не спрашивайте, почему второе число всегда равно 0;Я спрашивал несколько раз, но никто на самом деле не знает.У нас там не было ненулевого значения с тех пор, как в 1996 году была выпущена версия 5.5.