1

I'm having the same issue as nuget feeds and promotions, eight years later!

In this case I'm talking more generically; we're using ProGet as our package manager, and have nugets, universal packages, and even some docker containers to consider in the package promotion process.

One of the ideas is to have several Nuget feeds; a ci feed where every successful integration publishes a package, a qa feed that you only publish versions you want qa to test and then a release feed, where you copy only packages from the qa feed that they successfully tested.

So, say we have a build in the ci feed that works, it's version 1.2.3-ci-xyz. We want to promote that to the QA feed, without a rebuild, and re-package it as 1.2.3-rc-1. That package passes QA and is ready to be promoted into the prod feed, with no rebuild, and ship to production. It should ship as 1.2.3. (right?)

The question is, if we're not doing any rebuilds, the package binaries will still have the version 1.2.3-ci-xyz. That'll show up anywhere a version is displayed or queried in the app.

And that's where I get stuck. What's the proper pattern here? Does it matter what version is shipped, as long as we know what it is?

  • meaning, we promote 1.2.3-ci-xyz from lower feeds to higher feeds, without repackaging with different versions?
  • Wouldn't it be incorrect for package 1.2.3 to include a binary 1.2.3-ci-xyz?
  • do we always build with the next 3-digit number, and forget about the ci/rc suffix?
Max Cascone
  • 648
  • 9
  • 25

1 Answers1

1

I'll share this answer from our internal support channel :)

This is how we (Inedo) typically handle this in our libraries. The short answer is:

  • We set the Assembly Version to Major.Minor.Patch
  • We set the Assembly File Version to Major.Minor.Patch.Build
  • We set the Package version to Major.Minor.Patch-ci.Build (we then repackage to Major.Minor.Patch-rc.Build then to Major.Minor.Patch)
  • We also use the Assemble Informational Version to display a friendly version (ex: Version 6.0.0 (Build 36-v6))

This allows us to repackage without rebuilding. We also will detect these pre-release dependencies during our product builds and prevent them from being released to production. You can see our ProGet v6 build as an example: ProGet 6.0.0 Build 36.

The longer answer I feel is answered pretty well in our blog post Best Practices for Versioning NuGet Packages in the Enterprise.

Karl Harnagy
  • 717
  • 5
  • 10