Updates to releases.json (.NET Core release metadata)

**The changes described in this issue will be live with the .NET Core July update on 7/9/2019.**

The releases.json files (e.g. [2.2 releases.json](https://raw.githubusercontent.com/dotnet/core/master/release-notes/2.2/releases.json)) are comprehensive metadata files which capture details of each .NET Core release. These files, along with the top level [releases-index.json](https://raw.githubusercontent.com/dotnet/core/master/release-notes/releases-index.json), are becoming increasingly important .NET Core release assets. These files, one for each major.minor channel, are relied upon by many to detect when updates for .NET Core are available, discover security update details and other uses.

Changes are sometimes necessary, and the growing dependencies require that we treat compatibility of the schema with the utmost care. This announcement describes an addition to the releases.json schema.

## SDK Versions and Visual Studio

Because of current .NET Core SDK product construction dependencies, there is a hard link between the Runtime, SDK, toolset (compilers, MSBuild, NuGet, and other components), and Visual Studio. Simplistically, this means that when anything updates, everything updates. The unfortunate result of this linking is that multiple versions of the SDK are released with each monthly update for each supported versions of Visual Studio. For example, the May Update for .NET Core 2.2 included the 2.2.5 runtime, 2.2.107 SDK for Visual Studio 2017 and 2.2.204 for Visual Studio 2019 and yet another pair of SDK versions for .NET Core 2.1. An example of this is the [2.2.5 Release Notes](https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.5/2.2.5.md).

This is a confusing situation and we are working to mitigate the need to release multiple SDKs with .NET Core 3.0. The need for multiple SDK versions will persist for 2.1 LTS.

## Adding the SDKS array

To appropriately model multiple SDKs per release, we are adding an SDKs array to releases.json, which will contain SDK objects. The top-level SDK object will represent the highest versioned SDK for a given update. Using the previous 2.2.5 update example, SDK 2.2.204 is in the top SDK object as well as duplicated in the SDKS array. All other applicable 2.2* SDK objects are included in the SDKS array. The SDK objects within the array will carry specific Visual Studio compatibility and version inclusion information to provide appropriate context.

Here is an example of the new array based on the upcoming July update.
Again, this will be additive and the previous SDK object will include the highest SDK version for the release.

```json
{
"sdk": {
"version": "2.2.301",
"version-display": "2.2.301",
"runtime-version": "2.2.6",
"vs-version": "16.1.3",
"vs-support": "Visual Studio 2019 (v16.1)",
"csharp-version": "7.3",
"fsharp-version": "4.5",
"vb-version": null,
"files": []
},
"sdks": [
{
"version": "2.2.301",
"version-display": "2.2.301",
"runtime-version": "2.2.6",
"vs-version": "16.1.3",
"vs-support": "Visual Studio 2019 (v16.1)",
"csharp-version": "7.3",
"fsharp-version": "4.5",
"vb-version": null,
"files": []
},
{
"version": "2.2.205",
"version-display": "2.2.205",
"runtime-version": "2.2.6",
"vs-version": "16.0.5",
"vs-support": "Visual Studio 2019 (v16.0)",
"csharp-version": "7.3",
"fsharp-version": "4.5",
"vb-version": null,
"files": []
}
]
}
```

## vs-version and the Runtime

The same version of the runtime is included in multiple versions of Visual Studio. To account for this, the vs-version field is being updated to a comma-delimited string. The string will represent all versions of Visual Studio which first include the particular .NET Core update. Again, an example from the upcoming July Update.

```json
"runtime": {
"version": "2.2.6",
"version-display": "2.2.6",
"vs-version": "15.9.13, 16.1.3, 16.2.0",
```

The same `vs-versions` changes will be seen in the `aspnetcore-runtime` object.

## Future Enhancements

There are other improvements to the schema which have been suggested by the community which we are evaluating. Generally, theses enhancements are additive and should not represent compatibility compromises for existing parsers and similar announcements will be published ahead of any changes.