[Infra] Match runtime packages to runtime major version

[martincostello]

#5973 (comment)

Changes

Refactoring to match runtime packages to the major version of a target framework.

Unfortunately we can't do this complete for net8.0 without making breaking changes as we have exposed functionality that depends on new APIs added in the System.Diagnostics.DiagnosticSource package for 9.0.0.

opentelemetry-dotnet/src/OpenTelemetry.Api/Trace/TracerProvider.cs

Line 80 in 3f86f47

tracer = new(new(key.Name, key.Version, key.Tags));

opentelemetry-dotnet/src/OpenTelemetry.Api/Trace/TelemetrySpan.cs

Line 375 in 3f86f47

this.Activity!.AddLink(new ActivityLink(context, tags));

opentelemetry-dotnet/src/OpenTelemetry.Api/Trace/ActivityExtensions.cs

Line 125 in 3f86f47

activity.AddException(ex, in tags);

As a compromise for net8.0, 8.0.x packages are used for all dependencies except System.Diagnostics.DiagnosticSource which uses 9.0.0 to preserve these use cases.

The downside here is that users running net8.0 will technically be out of support for that package from May 2026, but that's still the case if we do nothing.

We could mitigate this by moving the special case for net8.0 to depend on the 10.0.0 package in November with a new release for .NET 10 (if that works) or users can self-mitigate by adding an explicit reference to the 10.0.0 version of that package to their own application without upgrading to .NET 10 immediately.

Moving forward to preserve the intention of this PR we would need to accept that new functionality would be gated to upgrading to the matching version of .NET. For example, a new feature added in .NET 10 would require your application to net10.0 to use it.

Alternatively we could take an approach where we only expose new APIs to older runtimes when the version is itself an LTS version.

In that case, a new API added in .NET 10 would be supported in all previous versions as we know the package exposing it is LTS, but a new API added in .NET 11 would only be available to net11.0 and later as that is STS.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.75%. Comparing base (a10f955) to head (a8d61f1).

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6327      +/-   ##
==========================================
+ Coverage   86.48%   86.75%   +0.27%     
==========================================
  Files         258      258              
  Lines       11879    11879              
==========================================
+ Hits        10273    10306      +33     
+ Misses       1606     1573      -33     

Flag	Coverage Δ
unittests-Project-Experimental	86.43% <ø> (+0.10%)	⬆️
unittests-Project-Stable	86.65% <ø> (+0.26%)	⬆️
unittests-Solution	86.40% <ø> (+0.02%)	⬆️
unittests-UnstableCoreLibraries-Experimental	85.87% <ø> (-0.38%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 7 files with indirect coverage changes

[paulomorgado]

Maybe this could be phrased to indicate that we need to (and can) use the latest version.

We, most likely, can use 10.0.x for all targets, like we can use 9.0.x.

For that matter, I'd use a property specific for this package's version.

[martincostello]

Depends on the resolution to this comment:

Moving forward to preserve the intention of this PR we would need to accept that new functionality would be gated to upgrading to the matching version of .NET. For example, a new feature added in .NET 10 would require your application to net10.0 to use it.

Alternatively we could take an approach where we only expose new APIs to older runtimes when the version is itself an LTS version.

The PR as-is is working on the assumption new things need newer TFMs/versions, so the MSBuild as-written is correct as it would only have an exception for net8.0 and code would need to use #if NET10_0_OR_GREATER-like constructs as appropriate for future API additions.

[martincostello]

I've also written it with #6307 in mind, where if this was merged as-is it would just add these changes:

- <RuntimePackageVersions>9.0.0</RuntimePackageVersions>
+ <RuntimePackageVersions>10.0.0</RuntimePackageVersions>
+ <RuntimePackageVersions Condition="'$(TargetFramework)' == 'net10.0'">10.0.0</RuntimePackageVersions>

[paulomorgado]

We should be prepared, but I'd reason about TFM specific stuff when we get there.

Polyfills are always an option. 😄

[eerhardt]

Build / verify-aot-compat / run-verify-aot-compat (ubuntu-22.04, net8.0) (pull_request)Failing after 1m

Try using 8.0.2 of Microsoft.Extensions.Configuration.Binder. The 8.0.0 package has bugs in the source generator that were fixed in patched versions.

[pjanotti]

This will help with conflict versions of Microsoft.Extensions.* when using opentelemetry-dotnet-auto