Rich Lander

Can you document the .NET and VS versions you had with the problem and w/o? That'd be helpful. It would also be good if you could share any msbuild logs...

I'm writing a bunch of k8s samples. I can add one for this. Describing all the patterns that require mounts (and how to do it correctly) would be very helpful....

For sure. We can do better. Also, if we were to come up with a short-link scheme, now would be the time to merge that in. Another point is that...

One way to avoid the breaking change is to create a peer to `releases-index.json`, with two options: - Stop adding new releases to file at .NET 8 (remove .NET 9...

Backing up, the large files we produce seem like an anti-pattern to me, in two ways: - Almost no one ever needs all (or most) of the data in our...

> we have used the historical information in the 'complete' releases.json on a number of occasions I don't see why this would ever be a problem. If there was a...

This probably isn't that hard. We just need to create another link here: https://github.com/dotnet/core/blob/f424bc4f5ddf45ceefe1c8a538e29ff62c6c8d4c/release-notes/releases-index.json#L14 Like: ```json { "channel-version": "9.0", "latest-release": "9.0.0-preview.1", "latest-release-date": "2024-02-13", "security": false, "latest-runtime": "9.0.0-preview.1.24080.9", "latest-sdk": "9.0.100-preview.1.24101.2", "product":...

I was also thinking about that. I think that's a good idea. We can then position the big `releases.json` as a legacy option.

> Just think of the `9.0/releases.json` to be named `9.0/releases-index.json` instead and the `9.0/releases.json` to look unchanged. Do you have a typo there? You mention `9.0/releases.json` twice. We'd be very...

I understand your wording now. My thinking is that we'd start this scheme with (for example) 8.0.3 and just move forward. Backporting the scheme would be nice, but it isn't...