Decide if SDK packages should be numbered after the SDK version or runtime version

Problem

For a given .NET release, there will unfortunately be two version numbers, the runtime version (like 8.0.5) used by the runtime, ASP.NET Core runtime, and Desktop runtime; and the SDK version (like 8.0.300).

Current behavior

This repository currently uses the runtime version (8.0.5) for all packages, even SDK packages, to simplify the dependencies and reduce confusion, with the assumption (and lack of official documentation refuting it) that this is harmless because SDKs and runtimes are always released in lockstep, or that runtimeless SDK releases are not useful to Raspberries Pi because they only introduce changes related to Visual Studio, which does not run on Debian.

Runtimeless SDK updates

However, in May 2024, an SDK update was released with no corresponding runtime release. SDK 8.0.300 was released after runtime 8.0.5 was released alongside SDK 8.0.205. This means that the SDK was not released in lockstep with a runtime, so this repository did not update to include SDK 8.0.300 (installing SDK 8.0.5 from this repository will still install SDK 8.0.205).

There is a suspicious lack of release notes for 8.0.300, and people are a little annoyed by this (see dotnet/core issue 9309). I assumed it was only released to make the SDK compatible with Visual Studio 17.10, but there are also breaking changes regarding <ManagePackageVersionsCentrally> and collection initializer type inference.

Question

Should the SDK packages generated by this repository use the SDK versions instead of the runtime versions, since there are actually important (if dumb) differences between them?

Comparison

Runtime version pros: simpler, consistent with runtime packages, dependencies are easier to declare, less state to track
SDK version pros: more faithful to upstream, allows runtimeless SDK updates to be published, runtimeless SDK updates sometimes have important (if dumb) differences from previous versions

Backwards compatibility

I don't think this is a backwards compatibility concern. Old versions of packages have never been preserved in this repository, for either SDKs or runtimes. Nothing really uses the SDK patch version, since no other internal packages depend on SDKs. Package names and minor versions won't change. The latest and latest-lts metapackages will be automatically updated to point to the new patch versions, so anyone with those installed will continue to get their updates transparently.

Aldaviva / RaspberryPiDotnetRepository