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

Question

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

У меня есть предварительные версии пакетов 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, даже включая пакеты перед выпуском...

Есть идеи здесь?

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

Answer 1

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

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

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**

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