switching version numbers from major.minor.build.revision to major.minor.patch

Topics: Ecosystem
Mar 24, 2013 at 5:21 PM
To date I've been versioning my nuget packages using the .net framework major.minor.build.revision [ http://msdn.microsoft.com/en-us/library/hdxyt63s.aspx ] format instead of the nuget packages major.minor.patch semantic versioning, aka semver, [ http://docs.nuget.org/docs/reference/versioning ] format.

If I want to now cut over and align with the nuget packages semver version numbering format should I expect that i can just drop the .revision number from my package version numbers and the gallery will do the right thing?

For example if I've been publishing "1.2.0.#" package versions and I publish my next drop as "1.2.#" should I expect the system to correctly interpret the "1.2.#" drops as the latest version number?
Mar 25, 2013 at 7:22 PM
yes. NuGet treats 1.2.# as 1.2.#.0
Apr 2, 2013 at 3:50 PM
Thanks for clarification.

It would appear that plenty of packages are using the 4 part versioning scheme instead of the 3 part semantic versioning scheme. Are there nuget ecosystem behaviors or features that I miss out on with my packages until I get to switching them from the 4 part format to the 3 part format?
Apr 3, 2013 at 3:19 AM
My suggestion is that nuget package version numbers should be independent of the assemblies'. For example, when I started to publish packages for the open source projects I manage,

  1. The assembly version number strictly follows Microsoft's approach on Visual Studio (as I use AssemblyInfo Task). The four-part format is meaningful for the developers to handle bug reports, but I think the last two parts are meaningless to the users. So for the nuget packages I only keep the first two parts the same as the assemblies.
  2. I noticed that sometimes I need to patch the nuget package alone (keep the binaries unchanged) because I missed something in the release notes, or I set a property wrongly, or I forgot to keep the framework hirarchy properly. In those cases I simply perform repackaging, and increase the fourth part (so get ..0.1). Well, in the future I might follow the SysVer recommendation to increase the third part.
But generally speaking, you have the freedom to use whatever way to manage the package version number, only if it does not break. :)
Apr 3, 2013 at 11:35 PM
@robertob You're not missing anything with the 3 part semantic versioning. We treat the two scheme exactly equally.

@lextm: We're not enforcing package version to match assembly versions. You're right, as a package authors, you are free to set the versions however you want, but of course we recommend you follow the standard convention, e.g. don't introduce breaking changes with a minor release, etc.