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

Я работаю над проектом .net С#, состоящим из решения с несколькими проектами библиотеки классов.

Управление исходным кодом управляется git с использованием gitflow в качестве модели ветвления. Мы решили реализовать семантическое управление версиями (http://semver.org/ ) проекта, чтобы следовать стандартному способу сообщения наших релизов. Для этого мы используем GitVersionTask (через NuGet), который довольно хорошо работает с gitflow.

Каждый раз, когда мы помечаем выпуск и выполняем сборку из основной ветки, версии всех сборок обновляются, и новый выпуск готовится к доставке. Только одна из сборок имеет общедоступный API, все остальные предназначены для внутреннего использования. Я хотел бы знать, является ли это правильным способом управления версией нескольких сборок одного и того же проекта, я имею в виду, не неправильно ли менять версию каждой сборки, когда была изменена только пара (или даже одна)? Чтобы усложнить мысль, существует большая вероятность того, что некоторые из «внутренних» сборок будут использоваться другими проектами, поэтому я считаю не очень разумным увеличивать основную версию сборки, которая не претерпела изменений, только потому, что другая сборка тот же проект продвигает критические изменения. Следует ли управлять каждым сборочным проектом в собственном репозитории?

Заранее спасибо.


semantic-versioning gitversion
person devrenew    schedule 22.08.2016    source источник
comment
Я бы управлял внутренними и внешними ресурсами в разных репозиториях. Нет причин публиковать внутренний код.   -  person Shawn    schedule 22.08.2016

Ответы (2)


arrow_upward
1
arrow_downward

Я знаю, что это немного старый вопрос, все же:

Я хочу поделиться обходным путем, который, кажется, работает:

  1. GitVersion использует $(Build.SourcesDirectory), чтобы увидеть, где находятся источники — src< /а>

  2. Мы можем изменить это, используя команды регистрации*

  3. Обходной путь — установить Build.SourcesDirectory перед задачей GitVersion.

  4. Затем gitVersion использует GitVersion.yml из папки проекта (Build.SourceDirectory) и вуаля — работает

После этого вы можете откатить изменение или нет - в зависимости от ваших потребностей. Мне кажется, неплохо ограничиться единственным пакетом nuget из коллекции пакетов nuget в нашем монорепозитории nugetPackages.

см. ошибку GitVersion и комментарий

*Пример команды Powershell: стандартная задача PowerShell; установить встроенный скрипт; Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$(Build.SourcesDirectory)\$(NugetProjectName)"

person Georgi    schedule 05.10.2018

arrow_upward
0
arrow_downward

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

person Gary Ewan Park    schedule 23.08.2016
comment
Допустим, в моем решении есть 3 проекта библиотеки классов с именами A, B, C. Когда я создаю решение, я получаю 3 сборки с именами A.dll, B.dll, C.dll. Все 3 проекта были созданы для удовлетворения потребностей этого конкретного продукта. Обе сборки A и B плотно прилегают к этому изделию и никогда не будут использоваться где-либо еще. С другой стороны, сборка C является автономной сборкой, очень полезной, поэтому, вероятно, будет включена в будущие продукты. Если я вас правильно понял, библиотека классов C должна управляться в своем собственном репо, а проекты A и B должны управляться в одном репо. Это верно? Спасибо. - person devrenew; 27.08.2016
comment
Да, именно такой подход я бы выбрал. - person Gary Ewan Park; 27.08.2016