We should create patch-release-specific release.json files.

With such a scheme, I'd expect to see:

• release.json at this location https://github.com/dotnet/core/tree/main/release-notes/8.0/8.0.1
• release-index.json at this location https://github.com/dotnet/core/tree/main/release-notes/8.0

The primary motivator for this is that releases.json can get very large:

• https://github.com/dotnet/core/blob/main/release-notes/6.0/releases.json
• https://github.com/dotnet/core/blob/main/release-notes/8.0/releases.json

This demonstrates the problem (and .NET 6 still has a ways to go):

$ curl -s https://raw.githubusercontent.com/dotnet/core/main/release-notes/6.0/releases.json | wc -l
   24680

That's 24k lines.

My hypothesis for JSON users:

• Most are satisfied with release-index.json (just looking for version numbers and the CVE bool).
• The vast majority of the remaining users only want to know about the latest release.
• Many of the users that need to look at all releases would prefer to read/process one release at a time to better control memory usage.

We could write a tool to backfill all the existing directories. That would be pretty easy. That could be done in parallel with establishing the scheme.

Related: #9205

@leecow