Разработка нумерации версий для приложения

Ответ 1

Мы используем major.minor [.build [.revision]]. И мы даем семантику:

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

Что касается сборки и редактирования:

0 - означает альфа-стадию.
1 - Бета.
2 - кандидат на выпуск.
3 - Производство.

Итак, если ваше приложение на 3.2.1.0. Вы знаете, что вы на альфа-стадии версии 3.2. И так далее.

ПРИМЕЧАНИЕ. Хотя может показаться что-то большим, чтобы включить ревизию, мы обнаружили, что это хорошая практика, потому что, если мы обнаружили ошибку или неожиданное поведение, мы просто исправляем и увеличиваем ревизию и не создаем.

Ответ 2

Я думаю - и это вытекает из моего опыта, а не только идеи - что вы должны использовать 4-ю версию номера версии - очень по линии @Randolf. Однако я бы сделал другое определение частей и версии.

major - это должно быть увеличено, когда версия является новой сборкой, несовместима с предыдущими версиями без процесса обновления или когда платформа сборки/разработки изменяется (так что переход от .net 2.0 к .net 4.0 будет засчитываться.

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

build - это всегда должно увеличиваться всякий раз, когда производится полная сборка производства, в качестве кандидата на выпуск.

revision - это должно быть обновлено для каждой сборки и использоваться для исправления ошибок в кандидате на выпуск.

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

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

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

Ответ 3

Удивительно, что .Net, по мнению многих людей, считает, что число построений является "неправильным". AssemblyInfo указывает номер сборки как [Major][Minor][Build][Revision], что для меня не имеет никакого смысла. Конечно, ночная сборка происходит чаще, чем пересмотр спецификации, и, следовательно, это "самое маленькое" изменение? Я не собираюсь бороться с каркасом, поэтому, я просто буду терпеть его.

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

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

Major: значительное обновление приложения, которое вы ожидаете от пользователей, если он будет коммерческим проектом. Пользователи должны ожидать столкнуться с проблемами инфраструктуры, такими как пакеты обновлений и новые версии .Net;

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

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

Пересмотр: должен соответствовать поправке к спецификации, по крайней мере концептуально. Обычно будет соответствовать элементу в списке изменений, то есть все дополнительные изменения вплоть до и без изменения запроса x.

Ответ 4

В BuildMaster мы рассмотрим формат номера #. #. #. # для представления:

[major version].[minor version].[maintenance version].[build number]

Поскольку в основном я бы срывал информацию из нашего блога, я просто дам вам ссылку на статью, написанную моим коллегой: http://blog.inedo.com/2011/03/15/release-numbering-best-practices/

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