Supported OS information now available as JSON

[richlander]

Supported OS information is now available in JSON format. These new files are a complement to the existing .NET release information available in JSON format.

Supported OS information has been available for many years as markdown files. Markdown is a great presentation format, but not for programmability. We now offer both markdown and JSON. In fact, the markdown files are now generated from the JSON.

We took the opportunity to improve the markdown format as part of this project. The OSes are now grouped by OS families and everything (families, OSes, architectures) are all in alpha-order. We also added a more useful end-of-life table at the end of the document modeled on past practice.

Note: We are waiting on dotnet/core #9367 to merge. The files are also not yet published to the locations in that PR. Once that all happens, it will be straightforward to get access to these new JSON files.

We will no longer be accepting PRs on the markdown files, but will direct updates to the JSON files. Anyone is free to propose updates to the JSON files if they find them to be incorrect.

Both the JSON and markdown files were created with data available from endoflife.date. This site is a valuable resource. Thanks to the maintainers for making it available!

You may notice that some operating system lifecycle data is missing. You are encouraged to contribute to endoflife.date if you are passionate about accurate data.

Thanks to @Falco20019 for working on this project. His insight and development effort helped make this new resource better for everyone.

[campersau]

The supported os versions tables are nice. Would it be possible to use ISO dates (yyyy-MM-dd) there too?
https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md#out-of-support-os-versions

[richlander]

Good idea.

I updated the format. How does it look?

[julealgon]

Markdown is a great presentation format, but not for programmability.

@richlander can you elaborate how this new file/format would be used in a program? Do you expect people to link directly to a github permalink to access these contents?

I ask because it is a bit unexpected to fetch Json directly from Github instead of from some sort of API that provides that data.

[richlander]

Does this PR answer your question?

https://github.com/dotnet/core/pull/9367/files

This is what I'm doing now: https://github.com/richlander/distroessed/blob/d18663c67f866312ac6cb6a1a4649dbd39412093/src/SupportedOsMd/Program.cs#L13

[julealgon]

Fair enough, thanks for sharing that use case.

I'd still expect this type of information to be exposed by an API but I see it has some usefulness even in "raw", direct github reference form.

[richlander]

People have made great use of releases.json w/o an API. An API really only makes sense if the result is subject to some input. It isn't in this case. We save on cost and complexity by serving data out of cloud storage. Serving JSON out of AWS S3, for example, is popular and the same pattern.

Case in point -- the entirety of this UI is driven by releases.json: https://dotnet.microsoft.com/download/dotnet

Static websites and files are all the rage. This is that.