Стратегия версий / обновления пакетов Nuget - PullRequest
Новая
       39

Стратегия версий / обновления пакетов Nuget

0 голосов
/ 03 ноября 2018

возможно, у кого-то есть хорошая идея для следующего сценария:

у меня есть предварительные версии пакетов dev, например: packagename.1.2.0.1000-dev.nupkg а также выпустить пакеты, например packagename.1.2.0.1.nupkg

Моя идея состояла в том, чтобы: начиная с более высокого диапазона номеров для пакетов dev, всегда можно было получить пакеты dev для разработчиков, если они включат опцию Pre-Release на этапе обновления nuget. Это отлично работает. Затем я хотел бы обновить проект до последней версии выпуска. Но кажется, что нет возможности обновить его до последней версии выпуска, которая имеет меньший номер версии, чем пакет dev / pre-release? Также опция -Safe здесь не работает.

Я не могу синхронизировать номера сборок, поскольку это разные сборки. Если бы у меня это было наоборот, поэтому более высокие номера сборки для версий выпуска, он никогда бы не обновился до последних пакетов dev, если бы я делал обычное обновление nuget, даже включая пакеты перед выпуском ...

Есть идеи?

Большое спасибо!

1 Ответ

0 голосов
/ 07 ноября 2018

Любой общедоступный пакет является «релиз-пакетом» в техническом / английском выражениях Но индустрия программного обеспечения убила язык. Итак, давайте поговорим о стабильных (без предварительной версии) и нестабильных версиях (предварительной версии).

История издателя должна выглядеть примерно так: 

1.0.0 // First **stable release**
1.0.1-alpha // First **unstable release** Candidate bug fix.
1.0.1-beta  // 1.0.1-alpha with a tweak to the code.
1.0.1 // Second **stable release**

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

Вы также можете иметь что-то вроде: 

1.0.0 // First **stable release**
1.0.1-a.dev.1 // Next CI build after 1.0.0
1.0.1-a.dev.2 // Etc...
1.0.1-alpha // Relabeled 1.0.1-a.dev.2.
1.0.1-beta  // Relabeled 1.0.1-alpha, wider audience than -alpha.
1.0.1 // Second **stable release**

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

...