Add Supported OS JSON files #9294

richlander · 2024-05-01T23:01:38Z

This is an proposal of a new schema for OS Support information. It is based on a collaboration with @Falco20019 with ideas developed in #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:

richlander · 2024-05-02T03:53:15Z

FYI: @martincostello

martincostello · 2024-05-02T05:59:58Z

release-notes/9.0/supported-os.json

+                        "arm64",
+                        "arm"
+                    ],
+                    "supported-cycles": [


Just curious, why is this termed "cycles" rather than "versions"?

We tried to keep the terminology close to https://endoflife.date/docs/api

Do we believe that it is a good name? I find this name very odd. We do not have to stick with bad names. This is not 1:1 mapping with that APIs.

I found release cycle fine, but have no hard feelings about using versions instead.

supported-release-cycles would be fine. The adjective is important to communicate the meaning.

supported-release-cycles would be fine.

But it is still not ideal. Release cycle is a repeatable process that produces releases. For example, take a look at how Ubuntu describes its current release cycle: https://ubuntu.com/about/release-cycle. This is not a list of the process variations. This is a list of what the process produced. So supported-releases or supported-versions would be even better.

cycles was an idea. I'm happy to switch to something more conventional.

release-notes/9.0/supported-os.json

MichaelSimons · 2024-05-02T13:27:43Z

Looping in @joeloff as the Microsoft.Deployment.DotNet.Releases library is going to need to react.

richlander · 2024-05-02T17:48:33Z

Having @joeloff react could be good. I assume there is no actual pressing reason since this information is purely additive not breaking.

richlander · 2024-05-02T19:02:07Z

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.

Falco20019 · 2024-05-03T06:50:17Z

I will give it a look later today and try to fill the holes if possible :)

Falco20019

We might want to split the supported-cycles up. Because there is the argument that Microsoft only gives technical support for OS that are maintained and not EOL and there is also the versions supported by the compile tool chain (SupportedOSPlatformVersion). These are different and both are of interest.

The minimum SupportedOSPlatformVersion is usually just one specific version (not an array) whereas the supported-cycles is usually an array where versions drop out once they are EOL in my opinion. supported-os.md mixes this up a bit. It talks about supported-cycles for Windows and Linux and about SupportedOSPlatformVersion for mobile platforms. SupportedOSPlatformVersion for Windows would be 10.0.17763.0.

Falco20019 · 2024-05-03T07:20:26Z

release-notes/9.0/supported-os.json

+                "source": "Ubuntu 16.04"
+            },
+            {
+                "architecture": "arm32",


I would stick with architectures as array instead of having a second alternative architecture as a single field. Makes automated processing easier.

Falco20019 · 2024-05-03T07:26:05Z

release-notes/9.0/supported-os.json

+                        "arm64"
+                    ],
+                    "supported-cycles": [
+                        "15+"


Mac Catalyst versions seem to correspond to iOS versions (and support lifetimes). The support linked to macOS seems more complex according to https://stackoverflow.com/a/69748714 but for this document, keeping it synced with iOS should be fine.

We can't really sync with iOS here since we support earlier iOS versions than what Mac Catalyst supports, using 15.0+ is correct here since it really depends on the lowest macOS version we support and which Mac Catalyst version that one ships with (i.e. 15.0 because we support macOS 12.0)

I also think this is mostly because of min-sdk and supported-cycles being mixed up. The min-sdk will be separate of iOS, the supported-cycles most probably not.

Falco20019 · 2024-05-03T07:55:15Z

release-notes/9.0/supported-os.json

+                        "arm"
+                    ],
+                    "supported-cycles": [
+                        "API 21+"


Android is a bit special since there are 3 different versions (compileSdkVersion, minSdkVersion and targetSdkVersion). Also support varies if using .NET MAUI for .NET 8 (API 21+) or .NET MAUI Blazor (API 24+).

TargetFramework is specifying the compileSdkVersion. When using i.e. net8.0-android34.0 the compileSdkVersion will be set to API 34. When using net8.0-android, the SDK is deciding itself what to use (usually pretty much latest). AFAIK, MSBuild also set's the targetSdkVersion in the manifest to that.

SupportedOSPlatformVersion is setting minSdkVersion, which is mostly for getting build warnings if some calls are not available and need workarounds. It's also used by the Play Store to specify which devices are supported and it's tested on.

targetSdkVersion/compileSdkVersion is mostly only the latest version and defaults are found here: https://learn.microsoft.com/en-us/dotnet/standard/frameworks#os-version-in-tfms

supported-cycles is really all about the minSdkVersion. Technically, this is API 21+ or 24+. In the supported-os I would more expect the real OS versions which would be 12, 12.1, 13, 14 and 15.

I would therefore propse here:

"supported-cycles": [ "12", "12.1", "13", "14", "15" ], "min-sdk-maui": "21", "min-sdk-blazor": "24"

While what you wrote is correct we have been using the API version instead of the Android OS version pretty much everywhere else, and it it's also what a user would set for SupportedOSPlatformVersion in the project file.

I'd prefer if we use API version for consistency.

My main issue is what I wrote here: #9294 (review)

The current supported-os.md is mixing up SupportedOSPlatformVersion and supported-cycles. SupportedOSPlatformVersion for Windows is not even mentioned anywhere.

For me as an end-user it's pretty hard to keep everything locally in sync because our end-customers are not interested in our SupportedOSPlatformVersion but about what OS we support them on. And I am interested on that as well from the perspective for what OS I get support from Microsoft if I stumble into issues. The documentation is currently only covering half of that and also not very consistent.

I would therefore like to see both things in the JSON. The real OS cycle supported (supported-cycles) but also the min supported technical SDK (SupportedOSPlatformVersion which for Android is already different between MAUI and Blazor). Maybe even calling it supported-min-sdk.

Yes I agree with that. We've been struggling to clearly define/separate

the minimum version an app will run on constrained by technical means i.e. min-sdk, min libc etc.

the minimum version we "officially" support which excludes EOL versions

The second one changes throughout a release as platforms go EOL but the first one we typically don't touch.

Similar discussion in #9038

#8880 can give you a better picture about where this thing started off from. I will also need to know basically through-out the live of a .NET version what was supported in the past and might not be supported anymore. Right now, I maintain that stuff in a biiiiiiiiiiig table (#8880 (comment))

In my opinion, the information about OS EOLs should be maintained separatedly and since the JSON files are generated according to @leecow should be taken into account when generating these to not manually maintain them in multiple locations. Otherwise the supported-cycles would need to be kept in sync for all .NET channels on each EOL.

The most important bit of data is supported OS, which aligns with "what we test and support". We should make sure that's captured. We've run into confusion in the past when we didn't have clarity on this.

What we target (with the compiler) is also important.

It seems like #9294 (comment) is a compromise that gives everyone what they want. I'm not seeing an obvious downside to this approach. Yes/No?

Falco20019 · 2024-05-03T08:00:47Z

release-notes/9.0/supported-os.json

+                        "arm64"
+                    ],
+                    "supported-cycles": [
+                        "12.2"


I would expect here the versions of 15+. 12.2 through 14.5 are already EOL. Maybe this is also something like a min-sdk version? I haven't used iOS builds myself so far. At least that seams to correspond to the SupportedOSPlatformVersion.

No, we still support iOS 12.2 as the minimum target an app can run on. It is similar to min-sdk on Android.

akoeplinger · 2024-05-03T08:28:03Z

release-notes/9.0/supported-os.json

+                    "architectures": [
+                        "x64",
+                        "arm64",
+                        "arm"


x86 is also supported on Android

Not according to https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md#android

akoeplinger · 2024-05-03T08:32:40Z

release-notes/9.0/supported-os.json

+                        "arm"
+                    ],
+                    "supported-cycles": [
+                        "API 21+"


While what you wrote is correct we have been using the API version instead of the Android OS version pretty much everywhere else, and it it's also what a user would set for SupportedOSPlatformVersion in the project file.

I'd prefer if we use API version for consistency.

akoeplinger · 2024-05-03T08:34:13Z

release-notes/9.0/supported-os.json

+                        "arm64"
+                    ],
+                    "supported-cycles": [
+                        "12.2"


No, we still support iOS 12.2 as the minimum target an app can run on. It is similar to min-sdk on Android.

akoeplinger · 2024-05-03T08:35:52Z

release-notes/9.0/supported-os.json

+                        "arm64"
+                    ],
+                    "supported-cycles": [
+                        "15+"


We can't really sync with iOS here since we support earlier iOS versions than what Mac Catalyst supports, using 15.0+ is correct here since it really depends on the lowest macOS version we support and which Mac Catalyst version that one ships with (i.e. 15.0 because we support macOS 12.0)

akoeplinger · 2024-05-03T08:38:44Z

release-notes/9.0/supported-os.json

+                        "14",
+                        "15",
+                        "16",
+                        "17"


I'm a bit confused why we use X.Y+ for one platform and explicitly list versions for other platforms.

In the current supported-os.md document we only specify the minimum platform version that we support running on.

Mainly because of the mixup of min-sdk and supported-cycles so far. supported-cycles will change during the lifetime of a .NET version due to EOL, min-sdk will usually not change anymore and is also only one version not a full list.

Falco20019 · 2024-06-20T06:26:41Z

release-notes/9.0/supported-os.json

                {
+                    "id": "ios",
                    "name": "iOS",
                    "lifecycle-policy": "https://support.apple.com/ios/",
                    "architectures": [
                        "arm64"


There are differences in supported architectures for iOS and the Simulator according to https://github.com/dotnet/core/blob/b488f858df2803b353233f38b16786913d6bcbc7/release-notes/9.0/supported-os.md#ios--tvos--maccatalyst which will be lost by your change. We would need to reflect that somewhere.

Falco20019 · 2024-06-20T06:29:58Z

release-notes/9.0/supported-os.json

-            "family": "Windows",
-            "distributions": [
-                {
-                    "name": "Nano Server",


Where do you intend to add the information about Nano Server and Windows Server Core? They have different support information, so I'm not sure if we can just refer to any of the remaining ones. Especially since Nano Server only supports x64.

release-notes/9.0/supported-os.json

Falco20019

Some remarks on missing or wrong versions.

release-notes/8.0/supported-os.json

release-notes/9.0/supported-os.json

Falco20019 · 2024-06-24T06:39:26Z

release-notes/9.0/supported-os.json

@@ -139,7 +145,7 @@
                        "Arm64",
                        "x64"
                    ],
-                    "supported-cycles": [
+                    "supported-versions": [
                        "40",
                        "39"


According to https://github.com/dotnet/core/blob/v9.0.0-preview.5/release-notes/9.0/supported-os.md only 40+ are supported by .NET 9 based on this commit: 56290a0#diff-4a789e8157a6362c43a84f58d12646edc31b264f899378cb553c381aafe60f37

Falco20019 · 2024-06-24T06:41:56Z

release-notes/9.0/supported-os.json

-                        "40",
-                        "39"
+                    "supported-versions": [
+                        "15.5"


You are missing 12.5.

15.2, 15.3 and 15.4 are still in LTSS, but I think it's fine to just skip them as .NET 9 on release never will have them supported.

.NET 8+ cannot run on 12.5, due to requiring glibc 2.23.

From 12.5

$ ldd --version
ldd (GNU libc) 2.22

That's interesting, since according to https://github.com/dotnet/core/blob/v8.0.0/release-notes/8.0/supported-os.md it was supported in the past (while the document was already mentioning glibc 2.23).

It was a mistake in .NET 8, then. I probably didn't notice it initially since I'm less familiar with Suse ecosystem. This time, I actually checked since we're doing a much more thorough job.

release-notes/9.0/supported-os.json

Falco20019 · 2024-06-24T07:14:34Z

release-notes/8.0/supported-os.json

+                    "link": "https://fedoraproject.org/",
+                    "lifecycle": "https://fedoraproject.org/wiki/End_of_life",
+                    "architectures": [
+                        "Arm32",


According to https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md Fedora is only supported on x64.

This list is about the architectures that .NET is available (supported?) on, right? IMO the list should be:

arm64

ppc64le

s390x

x64

.NET on Fedora is not available on Arm32 or x86.

release-notes/8.0/supported-os.json

Falco20019 · 2024-06-24T07:16:06Z

release-notes/8.0/supported-os.json

+                    ]
+                },
+                {
+                    "id": "opensuse",


Oracle Linux was dropped. Was this intentional?

Should be 8 + 9 on both .NET 8 & 9. Oracle Linux 7 is still in support was never supported by any of those two .NET versions according to the file history.

Yes. Oracle Linux is just one of many RHEL-compatible distros. I added a note to accomodate this.

Falco20019 · 2024-06-24T07:19:01Z

release-notes/8.0/supported-os.json

+                        "x64"
+                    ],
+                    "supported-versions": [
+                        "15.5"


SLES still supports 12.5 as well.

.NET 8+ cannot run on 12.5, due to requiring glibc 2.23.

From 12.5

$ ldd --version ldd (GNU libc) 2.22

richlander · 2024-06-24T17:54:57Z

Thanks for the feedback @Falco20019. That was very useful to get us towards more accurate info.

richlander · 2024-06-24T23:52:43Z

Should we add a supported-os property at this location:

core/release-notes/releases-index.json

Line 14 in 763e620

"release-type" : "sts",

?

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.

omajid · 2024-06-25T03:25:59Z

release-notes/8.0/supported-os.json

+                    "lifecycle": "https://access.redhat.com/support/policy/updates/errata/",
+                    "architectures": [
+                        "Arm64",
+                        "x64"


We should add s390x and ppc64le here.

I assume for 8 and 9?

Falco20019 · 2024-06-25T06:42:06Z

Should we add a supported-os property at this location:

core/release-notes/releases-index.json

Line 14 in 763e620

"release-type" : "sts",

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.

* Minor fixes * .NET 6 & 7 supported-os files * Generate MD files

release-notes/releases-index.json

* Re-add active versions to supported-versions on .NET 7 * Reformat EoL information * Prettify Windows names * Fix naming of prettify

richlander · 2024-06-26T16:53:13Z

#9370

Add initial JSON file

8a798cc

richlander requested review from rbhanda and leecow as code owners May 1, 2024 23:01

richlander marked this pull request as draft May 1, 2024 23:02

Update supported-os.json

fc13a88

martincostello reviewed May 2, 2024

View reviewed changes

Falco20019 reviewed May 2, 2024

View reviewed changes

release-notes/9.0/supported-os.json Outdated Show resolved Hide resolved

Removed most wildcards

1e39bec

Switch Windows version types

5c6d412

Falco20019 reviewed May 3, 2024

View reviewed changes

akoeplinger reviewed May 3, 2024

View reviewed changes

richlander added 3 commits May 3, 2024 09:50

Update per feedback

6ac80db

Update schema and remove some entries

b488f85

Update schema

f938445

Falco20019 reviewed Jun 20, 2024

View reviewed changes

richlander added 6 commits June 20, 2024 15:02

Update versions flagged by tool

7fcbbaf

Update Windows versions

f4de20f

Update Windows versions

1d56ab4

Add various OSes back

7149bc6

Add cycle to Windows

dff59df

Add notes

1a72876

Falco20019 reviewed Jun 21, 2024

View reviewed changes

release-notes/9.0/supported-os.json Show resolved Hide resolved

Falco20019 mentioned this pull request Jun 21, 2024

[new product] Microsoft Nano Server, Microsoft Windows Server Core endoflife-date/endoflife.date#5323

Merged

Update schema

1f967c7

richlander added 4 commits June 23, 2024 20:44

Merge branch 'main' into os-support

f0721ce

Add RHEL note

fd175eb

Correct Ubuntu versions

dbc44a1

Add generated MD files

0c842f6

Falco20019 suggested changes Jun 24, 2024

View reviewed changes

richlander added 2 commits June 24, 2024 10:49

Update per feedback

27e2cb4

Update per feedback

95ea716

richlander mentioned this pull request Jun 24, 2024

Update minimal supported Fedora version #7659

Closed

omajid reviewed Jun 25, 2024

View reviewed changes

Falco20019 mentioned this pull request Jun 25, 2024

Adding .NET 6 & 7 to #9294 #9366

Merged

Falco20019 and others added 2 commits June 25, 2024 09:42

Adding .NET 6 & 7 to #9294 (#9366)

2f2b4f8

* Minor fixes * .NET 6 & 7 supported-os files * Generate MD files

Update release-index and add RHEL architectures

0fc2a06

leecow approved these changes Jun 25, 2024

View reviewed changes

release-notes/releases-index.json Outdated Show resolved Hide resolved

Move release-index updates to separate PR

e9d2adb

richlander mentioned this pull request Jun 25, 2024

Add links to supported-os.json files #9367

Merged

Update generated markdown

db2225b

Falco20019 mentioned this pull request Jun 26, 2024

Regenerate .NET 7 JSON and Markdown files #9368

Merged

Falco20019 and others added 3 commits June 26, 2024 07:24

Regenerate .NET 7 JSON and Markdown files (#9368)

6ea55de

* Re-add active versions to supported-versions on .NET 7 * Reformat EoL information * Prettify Windows names * Fix naming of prettify

Regenerate MD

c02b6cf

Fix formattting

038c955

richlander merged commit fe79b58 into main Jun 26, 2024
5 of 6 checks passed

richlander deleted the os-support branch June 26, 2024 14:57

leecow mentioned this pull request Jul 17, 2024

Update dotnet releases-index to include new supported-os field. SchemaStore/schemastore#3927

Closed

richlander mentioned this pull request Jul 25, 2024

Release notes plan #9431

Open

xtqqczze mentioned this pull request Oct 10, 2024

macOS 10.15 reached end-of-life on 2022-09-12 #7999

Closed

xtqqczze mentioned this pull request Oct 25, 2024

Notifications about ending OS support #8880

Closed

Add Supported OS JSON files #9294

Add Supported OS JSON files #9294

Conversation

richlander commented May 1, 2024 • edited Loading

richlander commented May 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas Jun 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MichaelSimons commented May 2, 2024

richlander commented May 2, 2024

richlander commented May 2, 2024

Falco20019 commented May 3, 2024

Falco20019 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akoeplinger May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Falco20019 May 3, 2024 • edited Loading

Choose a reason for hiding this comment

akoeplinger May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Falco20019 May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akoeplinger May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Falco20019 Jun 20, 2024 • edited Loading

Choose a reason for hiding this comment

Falco20019 Jun 20, 2024 • edited Loading

Choose a reason for hiding this comment

Falco20019 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richlander commented Jun 24, 2024

richlander commented Jun 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Falco20019 commented Jun 25, 2024 • edited Loading

richlander commented Jun 26, 2024

richlander commented May 1, 2024 •

edited

Loading

jkotas Jun 23, 2024 •

edited

Loading

Falco20019 left a comment •

edited

Loading

akoeplinger May 3, 2024 •

edited

Loading

Falco20019 May 3, 2024 •

edited

Loading

akoeplinger May 3, 2024 •

edited

Loading

Falco20019 May 3, 2024 •

edited

Loading

akoeplinger May 3, 2024 •

edited

Loading

Falco20019 Jun 20, 2024 •

edited

Loading

Falco20019 Jun 20, 2024 •

edited

Loading

Falco20019 commented Jun 25, 2024 •

edited

Loading