Create release.json files per patch release

[richlander]

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

[leecow]

This sounds like a good improvement. I'll open a tracking issue in our internal tooling repo to track the necessary work.

/cc @rbhanda

[richlander]

Do you have any thoughts on the index file?

[richlander]

Here is a first take on the index format.

{
    "channel-version": "8.0",
    "support-phase": "active",
    "release-type": "lts",
    "release-date": "2023-11-08",
    "eol-date": "2026-11-10",
    "announcement": "https://devblogs.microsoft.com/dotnet/announcing-dotnet-8/",
    "release-notes": "https://github.com/dotnet/core/blob/main/release-notes/8.0/README.md",
    "lifecycle-policy": "https://aka.ms/dotnetcoresupport",
    "releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/releases.json",
    "supported-os.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/supported-os.json",
    "releases": [
        {
            "version": "8.0.7",
            "date": "2024-07-09",
            "security": true,
            "release.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/8.0.1/release.json"
        }
    ]
}

I noticed that @Falco20019 wrote some code that was looking for initial release date. I think we should include that as a first-class property.

[julealgon]

@richlander apologies upfront for the question, but is there some documentation around this whole concept of release.json files, their format, purpose, usages, etc?

This is the first time I hear about this (have just recently subscribed to the repo) and I'm curious, particularly if this has any applicability for other projects including our own.

[richlander]

Welcome! Great q. I added a document to a current PR that intends to offer that information.

https://github.com/dotnet/core/pull/9412/files#diff-697fd03ea53fdf95355fbf05df1973f5980f311d5e67dd141ad9ee87acf2e099

I'm also working on making it easy to consume these JSON files: https://github.com/richlander/distroessed/tree/linux-packages/src/DotnetRelease

These sites are based off of these JSON files:

• https://dotnet.microsoft.com/download/dotnet
• https://versionsof.net/

This file is generated from JSON: https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md

[Falco20019]

@richlander You are missing the VSMacVersion and VSMacSupport on RuntimeComponent and SdkComponent now that [JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)] is set in distroessed. I created richlander/distroessed#6 to fix it.

[richlander]

This is related: #9425

https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022

It doesn't seem like the VS for Mac properties have any value. I asked @leecow to stop generating them in all versions.