Establish .NET Runtime Support Policy

[halspang]

Background

The .NET SDK needs to establish a firm guideline on which versions of .NET it will build on and support in testing.

This topic comes up somewhat frequently, a quick scan gives at least two issues that have been created for different purposes and this conversation comes up in other mediums as well.

#1036
#925

As such, a firm and known stance for what we support is important.

Proposal

I propose that this SDK adopts Microsoft's support policy for .NET Core.

We will support the versions of .NET that are currently receiving patches/support. When a version of .NET is no longer listed as supported, the first release of this SDK after the date of deprecation will remove the framework from our build/testing.

This will keep us working with modern frameworks that are receiving updates for features, security, and bug fixes. Given the small nature of maintainers/approvers of this SDK, this also serves to lower the burden there and keep the SDK more focused.

For the main binaries, we will still target 1 release to build to. This will be the oldest LTS release (currently net6). We will then support all LTS and STS releases in our testing framework. Once the LTS release we're using as our build runtime is out of support, we'll move to the next LTS. For example, when net6 retires, we'll move to building with net8, skipping over net7.

This does mean that we won't be looking at supporting things like netstandard2.0/2.1. Again, this is mostly a maintenance issue, but it also allows us to focus on new functionalities and features.

[halspang]

It appears we've had this conversation before with @rynowak, another maintainer. #429

[yash-nisar]

I agree with the SDK adopting Microsoft's support policy and hence bumping up to net6.

[halspang]

Given the lack of discussion here and what was said in this issue, we'll adopt the Microsoft support policy for .NET: https://dotnet.microsoft.com/en-us/platform/support/policy.

After 1.11 is released, we'll remove any remaining references to anything < .NET 6. Going forward our releases will match that cadence so the first release after a version has gone EOL it will be removed from the SDK.

[philliphoff]

With 1.13, we moved to explicitly targeting both .NET 6 and .NET 8 (which were both under LTS at the time) as this allows the SDK to take advantage of advancements/optimizations of newer runtimes rather than a "lowest common denominator" approach.

With 1.14, explicit targeting of .NET 7 is considered "deprecated" (only Workflow explicitly targeted it anyway) and that target/testing will be removed for 1.15.

With 1.15, we will plan to continue targeting both .NET 6 and .NET 8 (as the expectation is that it will be still be under LTS by its release) but .NET 6 support will be considered "deprecated" (given LTS will be ended shortly thereafter) and target/testing will be removed for 1.16. An open question is whether 1.15 will explicitly target .NET 9 (though I'm leaning towards "yes" for the same reasons as doing so for both .NET 6 and .NET 8). If we should do so, then the target will equally applied across the SDK packages.

[WhitWaldo]

I think that if we're clear about following Microsoft's cadence regarding their own support cycle, it makes all the sense in the world to offer those performance benefits for anyone targeting the latest and greatest bits, even if it means that developmentally, we're bound to the lowest comment denominator in terms of language version.