Какую схему нумерации версий вы рекомендуете?
мой вопрос в том, какая схема именования версий должна использоваться для какого типа проекта.
очень распространенным является major.незначительный.исправить, но даже это может привести к номеру 4 (т. е. Firefox 2.0.0.16). Некоторые имеют модель, нечетные номера которой указывают на версии разработчика и четные номера стабильных выпусков. И всевозможные дополнения могут входить в микс, например-dev3, - rc1, SP2 и т. д.
существуют причины предпочесть одну схему другой и должны быть разные типы проектов (т. е. с открытым исходным кодом и с закрытым исходным кодом) имеют разные версии схемы именования?
12 ответов
здесь два хорошие ответы на это (плюс много личных предпочтений, см. комментарий подарка к религиозным войнам)
на public применения, стандартный майор.Незначительный.Пересмотр.Build works best IMO-публичные пользователи могут легко сказать, какая версия программы у них есть, и в какой-то степени, насколько устарела их версия.
на в доме применения, где потребители никогда не спрашивали для применения, развертывание обрабатывается им, и пользователи будут звонить в службу поддержки, я нашел год.Месяц.День.Стройте, чтобы работать лучше во многих ситуациях. Таким образом, этот номер версии может быть декодирован для предоставления более полезной информации в службу поддержки, а затем в общедоступную схему номеров версий.
однако в конце дня я бы сделал одну рекомендацию прежде всего - используйте систему, которую вы можете сохранить согласованной. Если есть система, которую вы можете настроить/написать компилятору автоматически использовать каждый раз,использовать.
самое худшее, что может произойти, это выпуск двоичных файлов с тем же номером версии, что и предыдущие - недавно я занимался автоматизированными отчетами об ошибках сети (кто-то elses application) и пришел к выводу, что год.Месяц.День.Построить номера версий, показанные в основных дампах, где даже отдаленно не в курсе самого приложения (само приложение использовало заставку с реальным числа-которые, конечно, не взяты из двоичного кода, как можно было бы предположить). В результате у меня нет способа узнать, поступают ли аварийные дампы из 2-летнего двоичного файла (что указывает номер версии) или 2-месячного двоичного файла, и, следовательно, нет способа получить правильный исходный код (нет управления версиями!)
вот что мы используем в нашей компании: основные.несовершеннолетний.патч версии.Номер Сборки .
на основные изменение включает полный цикл выпуска, включая участие в маркетинге и т. д. Это число контролируется силами, находящимися за пределами НИОКР (например, в одном из мест, где я работал, маркетинг решил, что наша следующая версия будет " 11 " - соответствовать конкуренту. Мы были в версии 2, в то время :)).
несовершеннолетний изменяется при добавлении в продукт новой функции или существенного изменения поведения.
патч версии поднимается на один каждый раз, когда патч официально добавляется в версию, обычно включая только исправления ошибок.
Строить Версии используется, когда специальная версия выпущена для клиента, обычно с исправлением ошибки, специфичной для него. Обычно это исправление будет свернуто для следующего исправления или незначительной версии (и управление продуктами обычно помечает ошибку как "будет выпущено для патча 3" в нашей системе отслеживания).
наш отдел НИОКР использует 1.0.0.0.0.000: майор.незначительный.заплатка.аудитория.критическая ситуация.build
пожалуйста, пожалуйста, не делай этого.
Я большой поклонник семантическое управление версиями
Как и многие другие прокомментировали это использует формат X. Y. Z и дает веские причины, почему.
этот вопрос больше касается религиозной войны, чем объективных аспектов. Всегда есть тонны плюсов и минусов против схемы нумерации или другой. Все, что люди могут (или должны) дать вам, - это схема, которую они использовали, и почему они ее выбирают.
с моей стороны, я использую схему X. Y. Z все числа, где:
- X укажите изменение в общедоступном API, которое вводит обратную несовместимость
- Y указать некоторые функции
- Z укажите исправление (либо исправление ошибки, либо изменение внутренней структуры без влияния функциональности)
В конце концов, я использую суффикс "Beta N", если мне нужна обратная связь от пользователей до официального выпуска. Нет суффикса" RC", поскольку никто не совершенен и всегда будут ошибки; -)
лично я предпочитаю майора.НЕЗНАЧИТЕЛЬНЫЙ.Исправление-суффикс, где суффикс dev для версий разработки (проверки контроля версий), rc1 / rc2 для кандидатов на выпуск и без суффикса для версий выпуска.
Если у вас есть суффиксы для проверок разработки, возможно, даже с номером ревизии, нет необходимости делать их четными/нечетными, чтобы держать их отдельно.
мы предпочитаем major.minor.milestone.revision-build схема, где:
-
major: инкременты на значительных архитектурноакустических изменениях или важных выдвижениях в возможностях. -
minor: небольшие изменения и новые функции, не требующие архитектурных изменений. -
milestone: указывает на стабильность и зрелость код:- 0 для разработки / pre-alpha
- 1 для Альфа
- 2 для бета
- 3 для кандидата на выпуск (RC)
- 4 для выпуска final / production
-
revision: указывает номер выпуска, исправления или исправления ошибок. -
build: уникальные ссылки на определенные сборки или версии приложения. Номер сборки-это последовательное целое число, обычно увеличивающееся при каждой сборке.
примеры:
-
1.4.2.0-798: первый бета-релиз версии1.4, созданный номер сборки798. -
1.8.3.4-970:1.8-RC4, созданный номером сборки970. -
1.9.4.0-986: первый выпуск версии1.9, созданный номером сборки986. -
1.9.4.2-990: второй выпуск исправления версии1.9, созданный номером сборки990.
поскольку выпуски prodcution всегда имеют 4 в 3-й цифра строку version, цифра может быть удален по выпуску продукции.
в случае библиотеки, номер версии говорит о уровень совместимости между двумя выпусками, и, таким образом, насколько сложным будет обновление.
выпуск исправления ошибок должен сохранять совместимость двоичного кода, источника и сериализации.
незначительные выпуски означают разные вещи для разных проектов, но обычно им не нужно сохранять совместимость с исходным кодом.
основные номера версий могут сломать все три формы.
Я написал больше об обосновании здесь.
с гибкими практиками разработки программного обеспечения и приложениями SaaS идея крупного и незначительного выпуска ушла - выпуски выходят очень часто на регулярной основе - поэтому схема нумерации выпусков, которая опирается на это различие, больше не полезна для меня.
моя компания использует схему нумерации, которая принимает последние 2 цифры года выпуска, а затем номер выпуска в течение этого года.
Итак, 4-й выпуск начался в 2012 году будет 12.4.
вы можете включить номер версии "исправление ошибок" после этого, если это необходимо, но в идеале вы выпускаете достаточно часто, что это не часто необходимо - так "12.4.2".
Это очень простая схема и не дала нам никаких проблем с другими схемами нумерации выпусков, которые я использовал раньше.
разница между закрытием и открытым исходным кодом номер версии политики также может исходить из коммерческий аспект, когда основная версия может отражать год выпуска, например.
то, что мы делали здесь, это майора.незначительный.платформа.исправить.
основные: мы увеличиваем это число, когда сохраненный файл из этой сборки больше не совместим с предыдущей сборкой.
Exemple: файлы, сохраненные в версии 3.0.0.0 не будут совместимы с версией 2.5.0.0.
несовершеннолетний: мы увеличиваем это число при добавлении новой функции. Эту функцию должен видеть пользователь. Не скрытая функция для разработчицей. Это число сбрасывается до 0 при увеличении major.
платформа: это платформа, которую мы используем для разработки.
Exemple: 1 означает .net framework версии 3.5.
исправить: мы увеличиваем это число, когда только исправления ошибок включены в эту новую версию. Это число сбрасывается до 0 при увеличении major или minor.