Как правильно обращаться с версией сборки?

Question

Я с нетерпением жду ежедневной сборки для будущего проекта.

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

У меня есть следующие проблемы:

• Должна ли каждая сборка иметь независимый номер версии или все они имеют одинаковую версию?
• Должен ли я использовать * версию для сборки и ревизии?
• Относится ли редакция к ежедневной сборке?

Answer 1

Мы штампуем все сборки в наших продуктах с одинаковым номером версии, выполнив следующие действия:

• Свяжите все сборки с AssemblyInfoCommon.cs, содержащий информация о номере версии: см. здесь для примера.

• Создание файла AssemblyInfoCommon.cs как часть сборки используя (в нашем случае) задачу NAnt asminfo, Cruise Control .NET и SVN revision labeller

В нашем случае мы не используем * версию. Все развернутые версии построены на сервере сборки. Мы не беспокоимся о номере версии на наших рабочих столах.

Answer 2

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

Схема, которую я использовал в предыдущей компании, была major.minor.revision.build - поэтому в версии 1.0 продукта версия сборки и версия файла сборки для каждой сборки была 1.0.0.1129 (например). Это позволило легко сопоставить, какие сборки были частью какого выпуска программного обеспечения, вплоть до номера сборки. Мы выполнили это с помощью поиска перед компиляцией и замены в каждом файле AssemblyInfo.cs, чтобы заменить токен номерами версий, предоставленными нашим автоматическим процессом сборки.

Answer 3

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

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

Answer 4

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

Что касается нумерации, я согласен с Гаем Старбаком (major.minor.revision.build). Я всегда так делал, и он всегда работал хорошо.

Answer 5

Таким образом, каждая сборка должна иметь одну и ту же версию, которая обычно является комбинацией версии выпуска, то есть 3.4 + номер сборки, который представляет собой последовательность, представляющую количество раз, которое выпуск был скомпилирован на сервере сборки. Редакция актуальна, потому что она показывает количество сборок, которые вы создали для этого выпуска. Вы можете сделать это одним из двух способов. Первый способ заключается в том, что если вы запланировали выпуск, т. Е. 3.4, то, когда вы начнете работать над этим выпуском, тогда это ваш основной номер версии и ваш дополнительный номер версии увеличиваются с сборкой. Еще один способ сделать это - жестко контролировать версии сборки, так как, когда вы будете готовы выпустить релиз для QA / Regression, вы устанавливаете основную версию на 3.4 и оставляете младший номер версии равным 0. Таким образом, вы держите вещи под жестким контролем пока вы не отпустите. Таким образом, вы можете контролировать нумерацию вашего пакета обновления через дополнительный номер версии. Надеюсь, это поможет.