Лучшие практики для именования сборок и управления версиями?

Question

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

В некоторых случаях я видел выпуски версий с версии 1.0 до 3.0. В других случаях, кажется, застрял в версии 1.0.2.xxxx.

Это будет для общей сборки, используемой в нескольких проектах по всей компании. С нетерпением ждем хороших отзывов.

Answer 1

Хорошая информация из этой статьи в блоге Сюзанны Кук на MSDN (опубликовано 2003-05-30):

Когда менять файл / версии сборки

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

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

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

Отгрузочные сборки
Что касается того, стоит ли менять эту версию для отгрузочных сборок, зависит от того, как вы хотите привязать к работать для конечных пользователей. Вы хотите, чтобы эти сборки были рядом или на месте? Много ли изменений между двумя сборками? Они сломать некоторых клиентов? Вас волнует, что это их ломает (или делает Вы хотите, чтобы пользователи использовали ваши важные обновления)? Если да, то вы следует рассмотреть возможность увеличения версии сборки. Но затем снова, Учтите, что выполнение этого слишком много раз может засорить пользовательский диск с устаревшими сборками.

При изменении версий сборки
Чтобы заменить жестко запрограммированные версии на новые, я рекомендую установить переменную для версии в заголовочном файле и заменяя жесткое кодирование в источниках на переменная. Затем запустите препроцессор во время сборки, чтобы вставить правильная версия. Я рекомендую менять версии сразу после доставки, не раньше, так что есть больше времени, чтобы поймать ошибки из-за изменить.

Answer 2

Один из способов определения версий - дать семантическое значение каждой части:

• Переход от N.x к N + 1.0, когда нарушается совместимость с новым реле
• Переход от N.M к N.M + 1 при добавлении новых функций, которые не нарушают совместимость
• Переход от N.M.X к N.M.X + 1 при добавлении исправлений ошибок

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

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

Answer 3

Семантическое управление версиями имеет ряд рекомендаций и правил относительно того, как применять это (и когда). Очень просто следовать, и это просто работает.

http://semver.org/

Answer 4

Первое, что я бы порекомендовал, это ознакомиться с различиями между версией сборки и версией файла. К сожалению, .NET имеет тенденцию рассматривать их как одинаковые, когда дело доходит до файлов AssemblyInfo, поскольку обычно он только устанавливает AssemblyVersion и позволяет FileVersion по умолчанию использовать то же значение.

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

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

CompanyName.Framework.Core 

если это часть большой библиотеки или просто

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

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

Почти в каждой версии схемы, которую я видел, первые две части - Major.Minor. Основной номер версии обычно увеличивается при больших изменениях и / или прерывистых изменениях, в то время как дополнительный номер версии обычно увеличивается, чтобы указать, что что-то изменилось, что не было критическим изменением. Два других числа значительно более субъективны и могут представлять собой «сборку» (которая часто равна значению серийной даты или последовательно обновляемому номеру, который меняется каждый день) и «номер редакции» или номер исправления. Я также видел их в обратном порядке (с указанием Major.Minor.Revision.Build), где build - это последовательно увеличивающееся число из автоматизированной системы сборки.

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

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

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx