comments

With further discussion with @pranavkm on Jabbr we concluded that the issue was that the changes about using AssemblyInformationalVersion to be the Nuget $version$ target if it's parsable as a SemVer was never communicated outside of the discussion forums.

I just encountered a similar problem - I can't tell if it's the same problem as @dotnetchris is having, but the symptoms are similar. In my case, I tracked it down to the following. In my .nuspec file, I'm referencing files like:
<files>

However, nuget.exe (1.6) (run in Package Manager Console with VS 2010 in release configuration) seems to be pulling my version info from the AssemblyVersion attribute of bin\Debug\MyLib.dll (which had an old build and therefore old number).

An easy way for me to repro - switch to Debug configuration and edit AssemblyInfo.cs to:
[assembly: AssemblyVersion("1.0.0.0")]

Do a rebuild all (debug). Then switch to Release configuration and edit AssemblyInfo.cs to:
[assembly: AssemblyVersion("1.2.1.0")]

Do a rebuild all (release). Then, in Package Manager Console, run "nuget pack MyLib\MyLib.csproj". I get the following output:

The NuGet package has version number 1.0.0.0, but the DLLs in the package are 1.2.1.0. I think if the assemblies being packaged are coming out of bin\Release, then $version$ should come from assemblies in bin\Release, not bin\Debug

No, I don't have an AssemblyInformationalVersion attribute set. It's pulling the right version out of the AssemblyVersion attribute, but for the wrong build (e.g., if I do a Debug build 1.2.0.0, then a Release build 1.3.0.0, and do the nuget pack as part
of the release post build, it will mark it version 1.2.0.0 (from the Debug build), ignoring the newer (and currently active) Release build. I tend to only pack release builds, so the debug build numbers are meaningless and would hopefully be ignored.