Какую схему нумерации версий вы рекомендуете?

На этот вопрос есть два хороших ответа (плюс множество личных предпочтений; см. Комментарий gizmo о религиозных войнах).

Для общедоступных приложений лучше всего подходит стандарт Major.Minor.Revision.Build IMO - общедоступные пользователи могут легко определить, какая у них версия программы и, в некоторой степени, насколько устарела их версия.

Я обнаружил, что для внутренних приложений, где пользователи никогда не запрашивали приложение, развертыванием занимается ИТ-отдел, а пользователи будут звонить в службу поддержки, во многих ситуациях Year.Month.Day.Build работает лучше. Таким образом, этот номер версии может быть декодирован для предоставления более полезной информации службе поддержки, чем общедоступная схема нумерации версий.

Однако, в конце концов, я бы дал одну рекомендацию, прежде всего - используйте систему, которую вы можете поддерживать. Если есть система, которую вы можете настроить / создать сценарий для вашего компилятора, чтобы он всегда автоматически использовался, используйте это.

Худшее, что может случиться, - это то, что вы выпускаете двоичные файлы с тем же номером версии, что и предыдущие - я недавно имел дело с автоматическими отчетами об ошибках сети (приложение для кого-то еще) и пришел к выводу, что Year.Month.Day. Номера версий сборки, показанные в дампах ядра, где даже удаленно не обновлены с самим приложением (само приложение использовало экран-заставку с реальными числами, которые, конечно, не были взяты из двоичного кода, как можно было бы предположить). В результате у меня нет возможности узнать, исходят ли аварийные дампы из двоичного файла двухлетней давности (что указывает номер версии) или из двоичного файла двухмесячной давности, и, таким образом, нет способа получить правильный исходный код (также нет контроля версий! )

Я большой поклонник семантического управления версиями

Как отмечали многие другие, здесь используется формат X.Y.Z и приводятся веские причины, почему.

Вот что мы используем в нашей компании: Основная. Незначительная. Версия исправления. Номер сборки.

Основное изменение включает в себя полный цикл выпуска, включая участие в маркетинге и т. Д. Это число контролируется силами, не связанными с исследованиями и разработками (например, в одном из мест, где я работал, отдел маркетинга решил, что наша следующая версия будет «11» - чтобы соответствовать конкуренту. На тот момент у нас была версия 2 :)).

Незначительное изменяется, когда к продукту добавляется новая функция или существенное изменение поведения.

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

Версия сборки используется, когда для клиента выпускается специальная версия, обычно с исправлением ошибки, характерной для него. Обычно это исправление будет добавлено к следующему патчу или второстепенной версии (и Управление продуктом обычно отмечает ошибку как «будет выпущена для исправления 3» в нашей системе отслеживания).

Наш отдел исследований и разработок использует 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Пожалуйста, пожалуйста, не делай этого.

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

Со своей стороны, я использую схему X.Y.Z. Все числа - числа, где:

• X указывают на изменение в общедоступном API, которое приводит к обратной несовместимости.
• Y обозначают добавление некоторых функций.
• Z указывает на исправление (либо исправление ошибки, либо изменение внутренней структуры без ущерба для функциональности).

В конце концов, я использую суффикс «Beta N», если хочу получить обратную связь от пользователей до того, как будет выпущен официальный релиз. Нет суффикса "RC", потому что никто не идеален и всегда будут ошибки ;-)

Мы предпочитаем схему _1 _._ 2 _._ 3 _._ 4 _-_ 5_, где:

• major: Приращения после значительных архитектурных изменений или важных улучшений в возможностях.
• minor: Небольшие изменения и новые функции, не требующие архитектурных изменений.
• milestone: Indicates stability and maturity of the code:
  • 0 for development/pre-alpha
  • 1 для альфа
  • 2 для бета
  • 3 для релиз-кандидата (RC)
  • 4 для финальной / производственной версии
• 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.

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

Лично я предпочитаю MAJOR.MINOR.BUGFIX-SUFFIX, где SUFFIX - dev для версий для разработки (проверка контроля версий), rc1 / rc2 для кандидатов на выпуск и без суффикса для версий выпуска.

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

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

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

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

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

Подробнее об обосновании я написал здесь.

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

Моя компания использует схему нумерации, которая состоит из двух последних цифр года начала выпуска и номера выпуска в этом году.

Итак, четвертый выпуск, запущенный в 2012 году, будет 12.4.

После этого вы можете добавить номер версии с «исправлением ошибки», если необходимо, но в идеале вы выпускаете достаточно часто, чтобы в этом не было необходимости - так что «12.4.2».

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

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

Раньше мы использовали major.minor.platform.fix.

major: мы увеличиваем это число, когда сохраненный файл из этой сборки больше не совместим с предыдущей сборкой.
Пример: файлы, сохраненные в версии 3.0.0.0, не будут совместим с версией 2.5.0.0.

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

платформа: это платформа, которую мы используем для разработки.
Пример: 1 означает .net framework версии 3.5.

fix: мы увеличиваем это число, когда в новую версию включены только исправления ошибок. Это число сбрасывается на 0 при увеличении старшего или младшего.

Просто

Major.Minor.Revision.Build