Получение номеров версий программного обеспечения. v1.0.0.1

Question

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

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

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

У вас есть бета-версии со своими номерами версий или у вас есть бета-версии на номер версии?

Answer 1

Я начинаю использовать соглашение Year.Release [.Build], которое используют некоторые приложения (например, Perforce). В основном это просто говорит год, в который вы отпустите, и последовательность в этом году. Таким образом, 2008.1 будет первой версией, и если вы выпустите еще несколько месяцев или три позже, она перейдет к 2008 году.

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

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

Answer 2

Использую V.R.M. 2.5.1

В (версия) изменения являются одной из основных переписать
R (пересмотра) изменения существенные новые функции или исправления ошибок
М (модификация) изменения незначительные исправления (BUX опечатки и т.д.)

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

1.1.2.3 

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

1.0.1.23 

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

автоинкрементные номера сборки часто приводит к номерам версий, как

1.0.1.12537 

, который на самом деле не поможет, либо.

Answer 8

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

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

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

15.2008.9.3 

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

Answer 9

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

Answer 10

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

YYYY.MM.DD.BuildNumber

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

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

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

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

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

Answer 11

На мой взгляд, почти любая схема номера выпуска может быть сделана для более или менее разумной работы. В системе, в которой я работаю, используются номера версий, такие как 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. Я очень беспокоюсь о том, что мой код, который должен работать как с 5x (старый стиль), так и с 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 - моя схема не может обнаружить изменения на уровне незначительного выпуска ... ворчать ... ворчать ...

NB: Eric Raymond обеспечивает Software Release Practice HOWTO включая раздел (ссылки) по наименованию (нумерация).

Answer 12

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

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

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

Answer 13

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

Answer 14

Мне нравится year.month.day. Итак, v2009.6.8 будет «версией» этого сообщения. Невозможно дублировать (разумно), и это очень ясно, когда что-то новое. Вы также можете удалить десятичные знаки и сделать это v20090608.

Answer 15

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

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

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

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

Я написал больше об обосновании here.

Answer 16

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

От http://semver.org/:

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

мажорной версии, когда вы делаете несовместимые изменения API, минорной версии при добавлении функциональности в backwards- совместимый способ и версию PATCH , когда вы делаете исправления ошибок с обратной совместимостью. Дополнительные метки для метаданных с предварительным выпуском и сборки доступны в виде расширений в формате MAJOR.MINOR.PATCH.