У меня есть среда, в которой я создаю несколько библиотечных решений в TFS. В конце процесса сборки скрипт упаковывает их в пакет NuGet и отправляет в наш локальный канал.
Теперь мы можем включать эти библиотеки, которые мало меняются изо дня в день, в наши исходные проекты.
Эти библиотеки, как и наши исходные проекты, обычно имеют одну и ту же версию. По сути, ствол — это наша развивающаяся последняя версия. Скажем, перед разветвлением ствола будет 3.0.0.123, где 123 — номер текущей сборки. В какой-то момент мы помечаем текущий ствол как то, что собираемся выпустить, и разветвляем его. Номер версии магистрали во время ветки становится версией этой ветки, и мы увеличиваем версию любым подходящим образом для магистрали до того, что, по нашему мнению, вероятно, будет следующим выпуском (скажем, 3.1.0.456). .
Это немного странно для того, как мы хотели бы использовать NuGet. Мы хотели бы, чтобы ветвь 3.0.0.456 использовала библиотеку lateset из ветки (возможно, 3.0.0.457), а магистраль использовала последнюю версию из магистральной линии (3.1.0.789).
Итак, в основном это сводится к тому, можем ли мы настроить версии решения с использованием NuGet так, чтобы они были аналогичны тому, как NuGet использует при определении зависимостей внутри пакета?
В идеале я хотел бы указать разветвленному вышестоящему приложению использовать [3.0.0.456, 3.1), а магистрали использовать последнюю версию (без версии). В этом сценарии он выберет ветку, которая выберет следующую сборку ветки (3.0.0.457), а магистраль выберет любой последний пакет NuGet, который был опубликован в канале.
Единственная идея, которую я придумал в качестве возможного решения, — это использование параметров для шаблона сборки и их использование для обновления файла package.config перед запуском целей NuGet.
Я извиняюсь, если это должно быть в SuperUser или где-то еще...
