core
core copied to clipboard
dotnet
Add Supported OS JSON files
This is an proposal of a new schema for OS Support information. It is based on a collaboration with @Falco20019 with ideas developed in https://github.com/dotnet/core/pull/9210/.
Once we agree, the intent is to merge this PR.
Goals:
- Extend https://github.com/dotnet/core/blob/main/release-notes/releases-index.json to include OS support information, per release.
- Enable using the JSON information anywhere where OS supported is needed (including generating the markdown files, for example https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md
- Make it easy to atomate changes to these files based on data maintained at https://endoflife.date/.
The endoflife site is pretty cool:
- https://endoflife.date/dotnet
- https://endoflife.date/api/dotnet.json
Having @joeloff react could be good. I assume there is no actual pressing reason since this information is purely additive not breaking.
I removed most of the wildcards. Two outstanding issues:
- I don't know what to include for Mac Catalyst.
- I'm sure that the Windows versions are correct.
I will give it a look later today and try to fill the holes if possible :)
We have libc documented here. Would it make sense to document libstdc++, too?
@sbomer @jkotas
I now have two good PoCs for using this schema. It feels pretty ergonomic and is trivial to use in conjunction with endoflife.date.
- https://github.com/dotnet/core/pull/9365/
- https://github.com/richlander/distroessed/
After working on this a bit, I came to the following philosophy (related to the feedback).
This is document is oriented on:
- OSes not targets.
- OSes not apps.
- Straightforward interop with Endoflife.date.
- Ergonomic reading/processing.
However, we can use notes for everything that doesn't fit that.
I think the current schema achieves that pretty well.
We have libc documented here. Would it make sense to document libstdc++, too? @sbomer @jkotas
I think documenting libc version is good enough. Versions of other libraries are effectively implied by libc version in the Linux ecosystem. Both our scheme and manylinux depend on this simplifying assumption.
We depend on number of libraries that come with the OS. Documentation version of all these libraries would be complicated.
Thanks for the feedback @Falco20019. That was very useful to get us towards more accurate info.
Should we add a supported-os property at this location: https://github.com/dotnet/core/blob/763e6208a661e158e799c243f23a0a540dbdad01/release-notes/releases-index.json#L14?
If so, what should the path be? A fully-qualified GH path or to the same Azure Storage path? IMO, a GH raw path is likely good enough. The information isn't of the same secure nature as the other information and it changes outside of the patch tuesday publishing schedule.
Thoughts?
Also, I was going to skip doing this exercise for .NET 6. If someone else wants to do that, that's fine with me.
Should we add a
supported-osproperty at this location:https://github.com/dotnet/core/blob/763e6208a661e158e799c243f23a0a540dbdad01/release-notes/releases-index.json#L14
I would vote for adding it. I even had it in my PR draft: https://github.com/dotnet/core/pull/9210/files#diff-8ea6e72f90234b0baa6218be158c9ebb2759894bcaf3ffe93c12bf330ffff0a8R12
Depending on how Azure Storage is updated, going with GH to have it always up2date might be the better approach.
Also, I was going to skip doing this exercise for .NET 6. If someone else wants to do that, that's fine with me.
I did it as #9366 (since I don't have permissions here). I would suggest to just merge it and discuss it here to avoid splitting discussion. I also added .NET 7 to be able to discuss how EOL products should be handled. As draft, I moved all releases into unsupported-versions.