Improve reporting of OS Name on macOS

[jamescrosswell]

Problem

In the .NET SDK for Sentry, on MacOS is we provide the Kernel Version in the context, whereas on Windows we provide a Version:

However the relay only looks for a value for os.version in the context (not kernel version): https://github.com/getsentry/relay/blob/24037f40afe892bf75bba3e74c4fc10c7f710bb1/relay-event-normalization/src/normalize/contexts.rs#L177-L179

This results in different behaviour on macOS than on Windows.

On Windows you end up with tags for os and os.name:

On macOS you end up with just the os.name:

Ideally macOS users would get something more human readable than Darwin 7 as well.

Solution Brainstorming

It might be possible to infer the os version from the kernal version (see here for example).

Whilst we could do this in the sentry-dotnet SDK, it seems like it would be better to put this in the relay so that other SDKs could benefit from the improvement as well.

Originally posted by @jamescrosswell in #2710

[Dav1dde]

Parsing this from the Kernel version doesn't seem very future proof and has the burden of it requiring constant updates.

Is it possible for the SDK to just include the version queried from the OS?

It seems to be available from the OS, e.g. I can query it with sw_vers:

└─ % sw_vers
ProductName:		macOS
ProductVersion:		14.7
BuildVersion:		23H124

└─ % cat /System/Library/CoreServices/SystemVersion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildID</key>
	<string>5234AC48-6B5F-11EF-B6EA-B3CD2D6CBC2E</string>
	<key>ProductBuildVersion</key>
	<string>23H124</string>
	<key>ProductCopyright</key>
	<string>1983-2024 Apple Inc.</string>
	<key>ProductName</key>
	<string>macOS</string>
	<key>ProductUserVisibleVersion</key>
	<string>14.7</string>
	<key>ProductVersion</key>
	<string>14.7</string>
	<key>iOSSupportVersion</key>
	<string>17.7</string>
</dict>
</plist>

So the SDK shouldn't parse it from the Kernel version either, but just hook into the correct source.

[jamescrosswell]

Thanks @Dav1dde, that makes sense. We'll see we can find an appropriate API to pull this info... it looks like it's readily available though.

[Dav1dde]

I'll close this for now in Relay, assuming you'll add it to the SDK(s) and query from an OS API.