Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Supported OS JSON files #9294

Merged
merged 38 commits into from
Jun 26, 2024
Merged

Add Supported OS JSON files #9294

Changes from 4 commits
Commits
Show all changes
38 commits
Select commit Hold shift + click to select a range
8a798cc
Add initial JSON file
richlander May 1, 2024
fc13a88
Update supported-os.json
richlander May 2, 2024
1e39bec
Removed most wildcards
richlander May 2, 2024
5c6d412
Switch Windows version types
richlander May 2, 2024
6ac80db
Update per feedback
richlander May 3, 2024
b488f85
Update schema and remove some entries
richlander Jun 19, 2024
f938445
Update schema
richlander Jun 19, 2024
7fcbbaf
Update versions flagged by tool
richlander Jun 20, 2024
f4de20f
Update Windows versions
richlander Jun 20, 2024
1d56ab4
Update Windows versions
richlander Jun 20, 2024
7149bc6
Add various OSes back
richlander Jun 20, 2024
dff59df
Add cycle to Windows
richlander Jun 20, 2024
1a72876
Add notes
richlander Jun 21, 2024
1f967c7
Update schema
richlander Jun 21, 2024
41f314f
Change libc schema
richlander Jun 22, 2024
5895cd8
Update architecture order
richlander Jun 22, 2024
6274f68
Update Arm casing
richlander Jun 22, 2024
ed9398d
Update architecture ordering
richlander Jun 22, 2024
7b7d5ec
Update Arm casing
richlander Jun 22, 2024
ba5c4cc
Include overall notes section
richlander Jun 22, 2024
f7136fc
Add notes about minimum target versions
richlander Jun 23, 2024
a7c4539
Update cycles -> versions
richlander Jun 23, 2024
a478591
Add additional Windows version
richlander Jun 23, 2024
521f24a
Add .NET 8 version
richlander Jun 23, 2024
73bae06
Update Windows supported versions
richlander Jun 24, 2024
f0721ce
Merge branch 'main' into os-support
richlander Jun 24, 2024
fd175eb
Add RHEL note
richlander Jun 24, 2024
dbc44a1
Correct Ubuntu versions
richlander Jun 24, 2024
0c842f6
Add generated MD files
richlander Jun 24, 2024
27e2cb4
Update per feedback
richlander Jun 24, 2024
95ea716
Update per feedback
richlander Jun 24, 2024
2f2b4f8
Adding .NET 6 & 7 to #9294 (#9366)
Falco20019 Jun 25, 2024
0fc2a06
Update release-index and add RHEL architectures
richlander Jun 25, 2024
e9d2adb
Move release-index updates to separate PR
richlander Jun 25, 2024
db2225b
Update generated markdown
richlander Jun 26, 2024
6ea55de
Regenerate .NET 7 JSON and Markdown files (#9368)
Falco20019 Jun 26, 2024
c02b6cf
Regenerate MD
richlander Jun 26, 2024
038c955
Fix formattting
richlander Jun 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
304 changes: 304 additions & 0 deletions release-notes/9.0/supported-os.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,304 @@
{
"channel-version": "9.0",
"last-updated": "2024-05-01",
"operating-systems": [
{
"family": "Android",
"distributions": [
{
"name": "Android",
"lifecycle-policy": "https://support.google.com/android",
"architectures": [
"x64",
"arm64",
"arm"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x86 is also supported on Android

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

],
"supported-cycles": [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@jkotas jkotas Jun 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

"API 21+"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Falco20019 Falco20019 May 3, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@akoeplinger akoeplinger May 3, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. the minimum version an app will run on constrained by technical means i.e. min-sdk, min libc etc.
  2. 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

Copy link
Contributor

@Falco20019 Falco20019 May 3, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#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))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

]
}
]
},
{
"family": "Apple",
"distributions": [
{
"name": "iOS",
"lifecycle-policy": "https://support.apple.com/ios/",
"architectures": [
"arm64"
Copy link
Contributor

@Falco20019 Falco20019 Jun 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

],
"supported-cycles": [
"12.2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

]
},
{
"name": "iOS Simulator",
"lifecycle-policy": "https://support.apple.com/ios/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"12.2",
"13",
"14",
"15",
"16",
"17"
]
},
{
"name": "tvOS",
"lifecycle-policy": "https://support.apple.com/apple-tv/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"12.2",
"13",
"14",
"15",
"16",
"17"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

]
},
{
"name": "tvOS Simulator",
"lifecycle-policy": "https://support.apple.com/apple-tv/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"12.2",
"13",
"14",
"15",
"16",
"17"
]
},
{
"name": "Mac Catalyst",
"lifecycle-policy": "https://support.apple.com/macos/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"15+"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@akoeplinger akoeplinger May 3, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

]
},
{
"name": "macOS",
"lifecycle-policy": "https://support.apple.com/macos/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"12",
"13",
"14"
]
}
]
},
{
"family": "Linux",
"distributions": [
{
"name": "Alpine",
"lifecycle-policy": "https://alpinelinux.org/releases/",
"architectures": [
"x64",
"arm64",
"arm"
],
"supported-cycles": [
"3.17",
"3.18",
richlander marked this conversation as resolved.
Show resolved Hide resolved
"3.19"
]
},
{
"name": "Debian",
"lifecycle-policy": "https://wiki.debian.org/DebianReleases",
"architectures": [
"x64",
"arm64",
"arm"
],
"supported-cycles": [
"11",
"12"
]
},
{
"name": "Fedora",
"lifecycle-policy": "https://fedoraproject.org/wiki/End_of_life",
"architectures": [
"x64",
"arm64",
"arm"
],
"supported-cycles": [
"39",
"40"
]
richlander marked this conversation as resolved.
Show resolved Hide resolved
},
{
"name": "openSUSE Leap",
"lifecycle-policy": "https://en.opensuse.org/Lifetime",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"15.5"
]
},
{
"name": "Red Hat Enterprise Linux",
"lifecycle-policy": "https://access.redhat.com/support/policy/updates/errata/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"8",
"9"
]
},
{
"name": "SUSE Enterprise Linux",
"lifecycle-policy": "https://www.suse.com/lifecycle/",
"architectures": [
"x64",
"arm64"
],
"supported-cycles": [
"39",
"40"
]
},
{
"name": "Ubuntu",
"lifecycle-policy": "https://wiki.ubuntu.com/Releases",
"architectures": [
"x64",
"arm64",
"arm"
],
"supported-cycles": [
"20.04",
"22.04",
"23.10",
"24.04"
]
}
]
},
{
"family": "Windows",
"distributions": [
{
"name": "Nano Server",
richlander marked this conversation as resolved.
Show resolved Hide resolved
"lifecycle-policy": "https://learn.microsoft.com/windows-server/get-started/windows-server-release-info",
"architectures": [
"x64"
],
"supported-cycles": [
"1809",
"2022"
]
},
{
"name": "Windows 10",
"lifecycle-policy": "https://support.microsoft.com/help/13853/windows-lifecycle-fact-sheet",
"architectures": [
"x64",
"x86",
"arm64"
],
"supported-cycles": [
"1607",
"1809",
"21H2",
"22H2"
]
},
{
"name": "Windows 11",
"lifecycle-policy": "https://support.microsoft.com/help/13853/windows-lifecycle-fact-sheet",
"architectures": [
"x64",
"x86",
"arm64"
],
"supported-cycles": [
"22H2"
]
},
{
"name": "Windows Server",
"lifecycle-policy": "https://learn.microsoft.com/windows-server/get-started/windows-server-release-info",
"architectures": [
"x64",
"x86"
],
"supported-cycles": [
"2012",
"2016",
"2019",
"2022"
]
},
{
"name": "Windows Server Core",
"lifecycle-policy": "https://learn.microsoft.com/windows-server/get-started/windows-server-release-info",
"architectures": [
"x64",
"x86"
],
"supported-cycles": [
"2012",
"2016",
"2019",
"2022"
]
}
]
}
],
"linux": {
"glibc": [
{
"architectures": [
richlander marked this conversation as resolved.
Show resolved Hide resolved
"arm64",
"x64"
],
"version": "2.23",
"source": "Ubuntu 16.04"
},
{
"architecture": "arm32",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

"version": "2.35",
"source": "Ubuntu 22.04"
}
],
"musl": [
{
"architectures": [
"arm32",
"arm64",
"x64"
],
"version": "1.2.2",
"source": "Alpine 3.13"
}
]
}
}
Loading