Рекомендации/рекомендации по поддержанию номеров версий сборки

Ответ 1

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

Далее предполагается, что вы используете какую-то форму управления версиями и сервер сборки. Для контекста мы используем TeamCity и Subversion/Git. TeamCity является бесплатным для небольшого (10) проектов и является очень хорошим сервером сборки, но есть и другие, некоторые из которых полностью бесплатны.

Что означает номер версии

То, что версия означает для одного человека, может означать что-то другое, другое - основная, второстепенная, макро, микро. То, как я смотрю номер версии, состоит в том, чтобы разбить ее на две части. В первом полугодии описывается основная версия (Major) и любые обновления ключей (Minor). Вторая половина указывает, когда она была построена и какова версия исходного кода. Номера версий также означают разные вещи в зависимости от контекста: API, веб-приложение и т.д.

Major. Minor. Build. Revision

• Revision Это номер, взятый из источника управления, чтобы определить, что был фактически построен.
• Build Это постоянно растущее число, которое можно использовать для поиска особенно на сервере сборки. Это важное число, поскольку сервер сборки, возможно, построил тот же источник дважды с другим набором параметры. Использование номера сборки в соединение с исходным номером позволяет определить, что было построено и как.
• Minor Это должно измениться только при значительном изменении открытый интерфейс. Например, если это API, потребляющий код по-прежнему может скомпилировать? Это число должно быть reset равным нулю при изменении основного номера.
• Major указывает, какая версия продукт, на котором вы находитесь. Например, Основные возможности VisualStudio 2008 сборки - 9 и VisualStudio 2010 составляет 10.

Исключение из правила

Всегда есть исключения из правила, и вам придется адаптироваться, когда вы сталкиваетесь с ними. Мой оригинальный подход был основан на использовании подрывной деятельности, но в последнее время я перешел на Git. Элемент управления источником, такой как подрывная и исходная безопасность, который использует центральный репозиторий, имеет число, которое может использоваться для идентификации определенного набора источников с определенного времени. Это не относится к управлению распределенным источником, например, Git. Поскольку Git использует распределенные репозитории, которые находятся на каждой машине разработки, нет автоматического увеличивающего числа, которое вы можете использовать, есть хак, который использует количество проверок, но он уродлив. Из-за этого мне пришлось развивать свой подход.

Major. Minor. Macro. Build

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

Что устанавливать

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

• 1.2.0.0 (AssemblyVersion)
• 1.2.3.4 (FileVersion)

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

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

Как подключить его вместе

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

• Удалите AssemblyVersion и AssemblyFileVersion атрибуты из всех файлов AssemblyInfo.cs проекта.
• Создайте общий информационный файл сборки (назовите его VersionInfo.cs) и добавьте его как связанный элемент во все ваши проекты.
• Добавить AssemblyVersion и AssemblyFileVersion атрибуты к версии со значениями "0.0.0.0".
• Создайте проект MsBuild, который создает файл решения.
• Добавить в задачу перед сборкой, которая обновляет VersionInfo.cs. Существует множество библиотек MsBuild с открытым исходным кодом, которые включают задачу AssemblyInfo, которая может установить номер версии. Просто установите его на произвольное число и тест.
• Добавить группу свойств, содержащую свойство для каждого из сегментов номера сборки. Здесь вы устанавливаете основное и второстепенное. Номер сборки и ревизии должен быть передан в качестве аргументов.

С subversion:

<PropertyGroup>
    <Version-Major>0</Version-Major>
    <Version-Minor>0</Version-Minor>
    <Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
    <Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
    <Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
    <Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>

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

• Номера версий в скомпилированной сборке
• Расширение MSBuild
• TeamCity

Ответ 2

[AssemblyVersion] очень важна в .NET. Одна из философий, поощряемая Microsoft, заключается в том, что вы позволяете ей автоматически увеличивать, заставляя все проекты, которые зависят от сборки, должны быть перекомпилированы. Работает нормально, если вы используете сервер сборки. Никогда не ошибаться, но остерегайтесь людей, несущих мечи.

Другой, более тесно связанный с его фактическим значением, состоит в том, что число является репрезентативным для управления версиями публичного интерфейса сборки. Другими словами, вы изменяете его только при изменении открытого интерфейса или класса. Поскольку только такое изменение требует, чтобы клиенты сборки были перекомпилированы. Это нужно сделать вручную, хотя система сборки недостаточно умна, чтобы автоматически обнаружить такое изменение.

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

Так что Microsoft проповедует не то, что она практикует. Его процесс сборки и управления версиями, однако, не имеют себе равных, у них даже есть специализированный инженер-программист, который контролирует процесс. Не так хорошо работает, перегрузка WaitHandle.WaitOne(int), в частности вызвала немалую боль. Исправлено в .NET 4.0 с совершенно другим подходом, но это немного выходит за рамки.

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

Ответ 3

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

[assembly: AssemblyVersion("1.0.*")]

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

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

Ответ 4

Добавляя к ответ Bronumskis, я хочу указать, что после стандарта Semantic Versioning 2.0 в semver.org, Major.Minor.Build.Revision будет незаконным из-за правила, что после увеличения числа все правильные значения справа должны быть reset равными нулю.

Лучше всего следовать стандарту - использовать Major.Minor+Build.Revision. Это не обязательно для использования в AssemblyVersionAttribute, но вместо этого может использоваться пользовательский атрибут или статический класс.

Semver в TeamCity должен быть доступен с использованием Meta-runter Power Pack. Для git с git -flow (особенно в мире .NET) я нашел GitVersion, чтобы быть полезным.

Ответ 5

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

... для ex: 1.0.0. *

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

Также подумайте о подписании сборки с сильным ключом. Это решит проблему конфликта сборки, если у вас есть несколько версий сборки, зарегистрированных в GAC. Ссылка MSDN