Demystifying .NET Core SDK versions

Last night I was developing some code in .NET Core for the Dutch Azure Meetup and I was (again) encountering versioning problems and unexpected behavior.
I found this blog post which describes in some way the same problem I had.
Update 13-01-2017: I found this blog which also describes very well the issue.
What the blog post says is that if you use:

dotnet new

and you want use a specific version of .NET Core SDK you should add a global.json file (before executing the “dotnet new” command) like this:

{
 "sdk": {
 "version": "1.0.0-preview2-003121"
 }
}

The SDK’s in Windows are installed in the Program Files folder (or Program Files (x86) if you have a 32bit Windows) so let’s take a look there:

The following SDK’s are installed om my machine:

• 1.0.0-preview2-003131
• 1.0.0-preview2-003133
• 1.0.0-preview2-003156
• 1.0.0-preview4-004233
• 1.0.0-preview2-1-003177

But how I know which SDK belongs to which .NET Core version?
Unfortunately Microsoft is not putting this information in the SDK folder’s names, they are using the CLI versioning in the folder names(!).
It seems they are aware of this annoying and odd naming convention:

In the following table I created an overview of the .NET Core versions and what kind of project the .NET Core CLI tooling is generating (json or csproj).

The .NET Core Team has decided to drop *.xproj/project.json and go back to MSBuild and *.csproj , check here

.NET Core 1.0.2 is missing in my overview, this is because this version was a patch for MacOS Sierra users,

So, let’s say you want to create a .NET Core application with 1.0.3, add a global.json file with this content:

{
    "sdk": {
        "version": "1.0.0-preview2-003156"
    }
}

And then run the command: dotnet new

Conclusion

The naming of the .NET Core SDK folder’s versions is not clear, this make difficult to choose the right one in your global.json file.
With the table overview above I hope to give more clarity what you should use.