Package version versus content version

Topics: General
Dec 20, 2014 at 3:57 PM
Suppose I made a package for a library CoolStuff of version 1.2.3. I called it cool-stuff.1.2.3.nupkg and pushed it to the public feed. Then I realized I forgot to add some content or messed up the metadata, or whatever, and I want to fix my package. How should I call the fixed package?

I cannot replace published package, and it is not right to increment package version since version of the library did not change. Package itself changed. It seems like NuGet lacks package version versus content version. How do I workaround this issue?
Dec 22, 2014 at 1:51 AM
You should then use separate version numbers for binaries and packages. Use my own projects as example, the RC NuGet packages usually contain the same binaries of the RTW packages, but their package numbers are different so users treat them differently.

My suggestion to your case, is to call the new package cool-stuff. You might use the last digit to indicate that this is a second package matching the binaries of 1.2.3. Meanwhile, at hide 1.2.3 version (as you cannot delete it).
Dec 22, 2014 at 7:31 AM
My suggestion to your case, is to call the new package cool-stuff.
That's what I'm actually doing now. But this method has two disadvantages:
  1. Some libraries already use all four numbers in their version, like OpenCV v2.4.10.1.
  2. I thought NuGet recommends to use Semantic Versioning, that makes me feel like the fourth digit may become deprecated in a while.
Dec 24, 2014 at 4:38 AM
Yes, correct. is only a temp solution. The ultimate solution I can see is to fully embrace Semantic Versioning for your packages.

In my planning phase, simply decide which is the next version number to use, such as 1.2.4. Then in development phase, publish 1.2.4-alpha, 1.2.4-beta, 1.2.4-rc packages at different stages. In the final testing phase, focus on 1.2.4-rc. If all passes, use the same binaries to build 1.2.4 package and RTW.

You can see that SemVer 2.0 even gives more flexibility on alpha/beta/rc part where you can use more segments for different purposes.

That's all for package versioning. You can use a completely different rules to manage the binary versioning.
Dec 24, 2014 at 1:34 PM
But what if after all my alpha, beta and rc I screwed up after all and need to fix my RTW package? These things may happen, though pre-releases lowers the probability.
Jan 3, 2015 at 3:03 AM
Just noticed that Microsoft has a staging environment, Then you can use that as your testing environment. Of course, there are other services such as MyGet to help out, and you can also build your own feed. NuGet is now becoming an ecosystem, than a single piece of software.