I didn't really get it until yesterday.
There are basically three major entities being versioned somewhat independently:
- The .NET Core 1.0 runtime, which is now at 1.0.4.
- The .NET Core 1.1 runtime, which is now at 1.1.1
- The .NET Core SDK/tools, which is now at 1.0.1. The version released with VS2017 is 1.0.0 because the most recent update barely missed the VS2017 train leaving the station.
Everything uses semantic versioning, i.e. major-minor-patch, with the associated rules around breaking changes and new functionality.
The 1.0 and 1.1 runtimes are both maintained for compatibility/supportability reasons - if you have an app that runs on 1.0, you can confidently take advantage of 1.0.4 immediately.
What you see when you run dotnet --version is the version of tooling you are using. The tools can output both 1.0.x and 1.1.x binaries. The tools hitting 1.0.0 yesterday was the biggest announcement, because it's been a circus - multiple "preview" releases, each with multiple point releases, as the CLI and functionality rapidly changed and (most importantly) support for the .csproj format was brought in. They dropped support for project.json/.xproj somewhere around preview4, but they kept maintaining older versions of the tools too to give people time to migrate away. Now that they're at 1.0.x, it's official and can be shouted from the rooftops: project.json/.xproj are gone, fully dead, no longer supported, don't use them, migrate away from them if you still have them, get rid of any old versions of the tools you have, move to the 1.0.x tools and don't look back.
There are basically two "families" of installers/packages/Docker images - those with the SDK and a version of the runtime, and those with only a version of the runtime. All installers/packages/Docker images are labeled with the runtime version number, because all of the SDK packages include the newest version of the tools, and the tools can target both the 1.0.x and 1.1.x runtimes.