Do not reference STS packages for non STS targets

[paulomorgado]

Using this package forces the use of STS libraries.

Users might have a mandate to only use LTS dependencies when available.

Target net8.0 should be using a Microsoft.Extensions.TimeProvider.Testing in the 8.0.x channel.

@DamianEdwards addressing this issue on ASP.NET Community Standup - .NET Aspire Q&A

[devlead]

Yes, this is a deliberate decision to build using the latest SDK and dependencies, ensuring a streamlined update process with Renovate for continuous maintenance.

Currently, all projects I maintain either target .NET 9.0 exclusively or support both .NET 9.0 and .NET 8.0 (primarily for legacy reasons). This approach aligns with the mandates of most of my current stakeholders, who prioritize staying up to date with the latest technology.

Additionally, in discussions with Microsoft, there has been no indication of quality degradation when adopting STS releases. .NET STS versions are fully supported in production, making them a viable choice for these projects.

Unless there is strong demand, broader support, or a personal need, this project will continue to align with the STS release cycle.

[paulomorgado]

It's not about quality, but supportability.

.NET 8.0 is not legacy and will be supported for longer than .NET 9.0.