Я распространяю программное обеспечение онлайн и всегда задаюсь вопросом, есть ли способ лучше определить номера версий.
Предположим, что A.B.C.D в ответах. Когда вы увеличиваете каждый из компонентов?
Используете ли вы какие-либо другие твиты номера версии, такие как D mod 2 == 1, означает, что это только релиз дома?
Есть ли у вас бета-версии со своими номерами версий или у вас есть бета-версии на номер версии?
Мне начинает нравиться соглашение Year.Release [.Build], которое используют некоторые приложения (например, Perforce). В основном это просто говорит год, в который вы отпустите, и последовательность в этом году. Таким образом, 2008.1 будет первой версией, и если вы выпустите еще несколько месяцев или три позже, она перейдет в 2008.2.
Преимущество этой схемы заключается в том, что не существует подразумеваемой "величины" выпуска, где вы получаете аргументы о том, достаточно ли функция достаточно велика, чтобы гарантировать увеличение основной версии или нет.
Дополнительным дополнительным является пометка на номер сборки, но это, как правило, только для внутренних целей (например, добавлено в EXE/DLL, чтобы вы могли проверить файл и обеспечить правильную сборку).
По моему мнению, почти любая схема номера выпуска может быть сделана более или менее разумной. В системе, в которой я работаю, используются номера версий, такие как 11.50.UC3, где U указывает 32-разрядную Unix, а C3 - небольшое количество исправлений (номер исправления); другие буквы используются для других типов платформ. (Я бы не рекомендовал эту схему, но она работает.)
Есть несколько золотых правил, которые до сих пор не были изложены, но которые подразумеваются в том, что обсуждали люди.
Теперь на практике людям приходится выпускать исправления для более старых версий, в то время как новые версии доступны - см. GCC, например:
Итак, вам нужно тщательно строить схему нумерации версий.
Еще один момент, в который я твердо верю:
С 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: Эрик Раймонд предлагает "Практика HOWTO по выпуску программного обеспечения" , включая раздел (связанный) об именах (нумерации).
Я обычно использую D как счетчик сборки (автоматический приращение компилятором) Я увеличиваю C каждый раз, когда сборка будет выпущена до "public" (не каждая версия выпущена) A и B используются в качестве основного/младшего номера версии и изменяются вручную.
Я думаю, что есть два способа ответить на этот вопрос, и они не совсем бесплатны.
Суть, я думаю, - найти модель, которая работает для вас и ваших клиентов. Я видел некоторые случаи, когда даже версии являются публичными релизами, а нечетные версии считаются бета-версиями или версиями dev. Я видел некоторые продукты, которые игнорируют C и D вместе.
Тогда есть пример из Micrsoft, где единственное рациональное объяснение номеров версий для .NET Framework заключается в том, что был задействован маркетинг.
Наша политика:
Люди склонны делать это намного сложнее, чем это действительно должно быть. Если ваш продукт имеет только одну долгоживущую ветвь, просто укажите последовательные версии по их номеру сборки. Если у вас есть какие-то "незначительные исправления ошибок, которые бесплатны, но вы должны платить за крупные новые версии", то используйте 1.0, 1.1... 1.n, 2.0, 2.1... и т.д.
Если вы не можете сразу выяснить, что такое A, B, C и D в вашем примере, то вам, очевидно, они не нужны.
Единственное, что я когда-либо делал из номера версии, было так, что клиент мог сказать мне, что они используют версию 2.5.1.0 или что-то еще.
Мое единственное правило предназначено для минимизации ошибок при представлении этого числа: все четыре числа должны быть только 1 цифрой.
1.1.2.3
нормально, но
1.0.1.23
нет. Клиенты, вероятно, сообщают обоим номерам (по крайней мере, устно) как "один-один-два-три".
Автоматически увеличивающиеся номера сборки часто приводят к номерам версий, таким как
1.0.1.12537
что тоже не помогает.
Хорошая и нетехническая схема просто использует дату сборки в этом формате:
YYYY.MM.DD.BuildNumber
Где BuildNumber является либо непрерывным числом (списком изменений), либо просто начинается с 1 дня в день.
Примеры: 2008.03.24.1 или 2008.03.24.14503
Это в основном для внутренних выпусков, публичные выпуски будут видеть версию, напечатанную как 2008.03, если вы не выпускаете ее чаще, чем раз в месяц. Освобождения от технического обслуживания отмечены как 2008.03a 2008.03b и так далее. Они должны редко проходить мимо "c", но если он делает это хорошим индикатором, вам нужны более качественные QA и/или процедуры тестирования.
Поля версии, которые обычно видны пользователю, должны быть напечатаны в дружественном формате "March 2008", зарезервируйте дополнительную техническую информацию в диалоговом окне "О программе" или в файлах журнала.
Самый большой недостаток: просто компиляция того же кода в другой день может изменить номер версии. Но вы можете избежать этого, воспользовавшись списком изменений управления версиями как последним номером и проверив это, чтобы определить, нужно ли также менять дату.
Я использую V.R.M, например. 2.5.1
Изменения V (версии) являются основным переписанием
Изменения R (изменения) являются значительными новыми функциями или исправлениями ошибок
Изменения M (модификации) являются незначительными исправлениями bux (опечатки и т.д.)
Иногда я также использую номер фиксации SVN на конце.
Все это действительно субъективно в конце дня и просто до вас/вашей команды.
Просто взгляните на все ответы уже - все очень разные.
Лично я использую Major.Minor.*.* - где Visual Studio автоматически заполняет номер ревизии/сборки. Это используется там, где я тоже работаю.
Хорошая дружественная схема управления версиями, созданная на старой Mac OS, описана в этой технической заметке Apple: http://developer.apple.com/technotes/tn/tn1132.html
Мне нравится Year.Month.Day. Итак, v2009.6.8 будет "версией" этого сообщения. Невозможно дублировать (разумно), и это очень ясно, когда что-то новое. Вы также можете удалить десятичные знаки и сделать это v20090608.
В случае библиотеки номер версии сообщает вам о уровне совместимости между двумя версиями и, следовательно, насколько сложно будет обновление.
Релиз исправления ошибок должен поддерживать совместимость с двоичным кодом, источником и сериализацией.
Малые релизы означают разные вещи для разных проектов, но обычно им не нужно сохранять совместимость с исходниками.
Основные номера версий могут разбивать все три формы.
Я написал больше об обосновании здесь.
В мире github стало популярным следовать спецификации Тома Престона-Вернера "semver" для номеров версий.
Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте значение:
ОСНОВНАЯ версия, когда вы делаете несовместимые изменения API, версия MINOR когда вы добавляете функциональность обратно-совместимым образом и PATCH когда вы делаете исправления ошибок с обратной совместимостью. дополнительный ярлыки для метаданных предварительного выпуска и сборки доступны в виде расширений в формате MAJOR.MINOR.PATCH.
Для внутренней разработки мы используем следующий формат.
[Program #] . [Year] . [Month] . [Release # of this app within the month]
Например, если сегодня я выпускаю приложение № 15, и это третье обновление в этом месяце, то моя версия # будет
15.2008.9.3
Это совершенно нестандартное, но оно полезно для нас.
В течение последних шести основных версий мы использовали M.0.m.b, где M - основная версия, m - младшая версия, b - номер сборки. Так выпущенные версии включали 6.0.2, 7.0.1,..., до 11.0.0. Не спрашивайте, почему второе число всегда 0; Я спрашивал несколько раз, и никто не знает. У нас не было отличного от нуля, так как 5.5 был выпущен в 1996 году.