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

Question

Во-первых, я думаю, что этот форум не подходит для моего вопроса, поэтому, если он находится не в том месте, прошу прощения и место, где это уместно.Я не нашел подходящего форума для моего вопроса.

Я разработал приложение на C # (Win Forms).Теперь мне нужно обработать его нумерацию версий.Я не могу понять, что это лучший способ сделать.Я хочу, чтобы номер версии был простым, например, 1.2 или 1.2.1.Я читал о версии SVN, но это также кажется немного запутанным на данном этапе.Существуют разные типы версий приложения - 1 с установщиком и 1 без установщика.

Я думаю, что версия выпуска и версия для разработки должны совпадать - пожалуйста, исправьте меня, если я ошибаюсь.Должен ли он быть обработан автоматически или изменен вручную?Каков наилучший, простой и легкий способ справиться с нумерацией версий приложения.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

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