В релизной конфигурации билда отключена прямая линковка к проектам, вместо этого используется линковка нагет пакетов.
Каждый пакет имеет список зависимостей NextApi которые могут настраиваться отдельно.
Разберем пример, используя схему зависимостей выше, давайте представим что мы поменяли что-то в NextApi.Server.
В текущей реализации нужно собирать все пакеты от которых NextApi.Server зависит: NextApi.Server.Common, NextApi.Common.
Последний пакет необходимо перестраивать, потому, что NextApi.Server косвенно через NextApi.Server.Common зависит от NextApi.Common.
Разберем еще один пример, более сложный по части зависимостей. Представим что нам нужно сделать мелкую правочку в NextApi.Testing.
После того как мы выложили код, нам нужно перестроить не только сам измененный пакет, но и все дерево зависимостей, а это: NextApi.Common, NextApi.Server.EfCore, NextApi.Client.
Теперь можно перестраивать только измененные пакеты. Для этого необходимо просто поддерживать конфигурацию минимальных версий для каждого пакета.
Разберем пример данной конфигурации, для пакета NextApi.Testing с правилом постройки:
nugetize-testing:
<<: *nugetize
variables:
projectFolder: src/base/NextApi.Testing
projectName: NextApi.Testing
NEXTAPI_CLIENT_VERSION: "3.0"
NEXTAPI_EFCORE_VERSION: "3.0"В данной конфигурации NEXTAPI_CLIENT_VERSION со значением '3.0' говорит о том, что данный пакет требует последнюю версию с индексом 3.0.. То есть Nuget понимает, что он может установить максимальную версию зависимость которая не выходит за пределы диапазона 3.0. >= versionToInstall < 3.1.*. Аналогичное описание для NEXTAPI_EFCORE_VERSION.
Мы будем использовать SemVer: https://semver.org, выдержка которая нам нужна:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and .
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
В конечном итоге новые версии NextApi будут выходить в формате major.minor.ciBuildId, где ciBuildId номер пайплайна в Gitlab.
Менять мажорную версию мы будем, только в случае breaking change функционала, в других случаях нужно внедрять новые функций с поддержкой обратной совместимости.
Простой случай, когда Nuget будет устанавливать пакет в Ваш проект, он подберет максимально доступную версию для зависимостей по шаблону 3.0.*. Допустим на сервере есть версии 3.0.200, 3.0.201, 3.0.202. Nuget установит 3.0.202. Также можно устанавливать и фиксировать версии вручную.
В релизной конфигурации билда отключена прямая линковка к проектам, вместо этого используется линковка нагет пакетов.
Каждый пакет имеет список зависимостей NextApi которые могут настраиваться отдельно.
Разберем пример, используя схему зависимостей выше, давайте представим что мы поменяли что-то в NextApi.Server.
В текущей реализации нужно собирать все пакеты от которых NextApi.Server зависит: NextApi.Server.Common, NextApi.Common.
Последний пакет необходимо перестраивать, потому, что NextApi.Server косвенно через NextApi.Server.Common зависит от NextApi.Common.
Разберем еще один пример, более сложный по части зависимостей. Представим что нам нужно сделать мелкую правочку в NextApi.Testing.
После того как мы выложили код, нам нужно перестроить не только сам измененный пакет, но и все дерево зависимостей, а это: NextApi.Common, NextApi.Server.EfCore, NextApi.Client.
Теперь можно перестраивать только измененные пакеты. Для этого необходимо просто поддерживать конфигурацию минимальных версий для каждого пакета.
Разберем пример данной конфигурации, для пакета NextApi.Testing с правилом постройки:
В данной конфигурации NEXTAPI_CLIENT_VERSION со значением '3.0' говорит о том, что данный пакет требует последнюю версию с индексом 3.0.. То есть Nuget понимает, что он может установить максимальную версию зависимость которая не выходит за пределы диапазона 3.0. >= versionToInstall < 3.1.*. Аналогичное описание для NEXTAPI_EFCORE_VERSION.
Мы будем использовать SemVer: https://semver.org, выдержка которая нам нужна:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and .
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
В конечном итоге новые версии NextApi будут выходить в формате major.minor.ciBuildId, где ciBuildId номер пайплайна в Gitlab.
Менять мажорную версию мы будем, только в случае breaking change функционала, в других случаях нужно внедрять новые функций с поддержкой обратной совместимости.
Простой случай, когда Nuget будет устанавливать пакет в Ваш проект, он подберет максимально доступную версию для зависимостей по шаблону 3.0.*. Допустим на сервере есть версии 3.0.200, 3.0.201, 3.0.202. Nuget установит 3.0.202. Также можно устанавливать и фиксировать версии вручную.