Create `release.json` files per patch release

richlander commented 1 month ago

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:

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.

@leecow

leecow commented 1 month ago

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 commented 1 month ago

Do you have any thoughts on the index file?

richlander commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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:

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

Falco20019 commented 1 month ago

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

richlander commented 1 month ago

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.

dotnet / core

Create `release.json` files per patch release #9417