Documentation request: statement on .NET Platform Extensions' support for previous versions of runtime targets

[daiplusplus]

• I saw this QA today: https://stackoverflow.com/questions/74159708/are-microsoft-extensions-libraries-intended-to-be-backward-compatible#comment130934545_74159708 - though the TL;DR: is:

  • .NET Platform Extensions' libraries' versions correspond with the current version of .NET, for example, the current latest version of Microsoft.Extensions.Logging as of October 2022 is version 6.0 to go-along with .NET 6.
  • ...but somewhat surprisingly these Platform Extensions libraries aren't just a sidekick for their .NET big-brother, but they support a much wider range of .NET runtime versions than you'd think... indeed, Microsoft.Extensions.Logging/6.0.0 doesn't actually have any dependencies on .NET 6, and in-fact, still supports .NET Framework 4.6.1.
  • ...which is great, honestly (as plenty of my projects are stuck on .NET Fx 4.8), but I don't know if I can depend on the Platform Extension libraries always supporting versions of .NET much older than the corresponding version of the Platform Extension library (i.e. Microsoft.Extensions.Logging/6.0.0 does not have a hard dependency on .NET 6), so I spent too much time searching online for some official documentation page, an official statement, or even a devblog article, but I couldn't find anything resembling a statement-of-commitment regarding .NET Platform Extensions' libraries support for older .NET runtimes.

• Here are some of the pages I did find, and note their lack of content w.r.t. support/lifecycle/targets/etc for .NET Platform Extensions libraries:

  • The "homepage" of the .NET Platform Extensions API documentation is the first place I'd expect to see a summary or explanation of compatibility or support, but nope.
    • Nothing here either: https://learn.microsoft.com/en-us/dotnet/standard/runtime-libraries-overview
  • The next place I looked was all the pages re: .NET Support and Lifecycle...
    • https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
    • https://github.com/dotnet/core/blob/main/microsoft-support.md
    • https://github.com/dotnet/core/blob/main/os-lifecycle-policy.md?WT.mc_id=dotnet-35129-website
  • No obvious .md files in the dotnet/runtime repo either.

Describe the new article

Something like this FAQ... except with answers, and signed-off by the head-honchos of .NET who can speak authoritatively, of course:

.NET Platform Extensions

• What is/are the .NET Platform Extensions?
  (This is not currently explained in the .NET glossary)
• Why do .NET Platform Extensions' versions coincide with major releases of .NET, but in don't actually have dependencies on those .NET releases and even support the oldest still-supported .NET runtimes?
• What is the official support/lifecycle/policy for the .NET Platform Extensions libraries?
• Why is some functionality in-box in the runtime and other functionality delegated to optional libraries? What's the decision-process for deciding where something goes?

[EnricoMassone]

Hello I'm the original author of the QA question mentioned above. It would be great to get some clarifications on this topic.

Issue #27315 refers to the same problem.
There is also a twitter conversation about this topic, which is referenced in some blogs and discussions related with ASP.NET core applications migration.

I guess it's a common problem for any team which maintains ASP.NET core applications and a bunch of utilities libraries. It's quite common for utility libraries for the .net core environment to take a reference over Microsoft.Extensions.* packages.
Each time there is a migration of the team applications from a .net core LTS version to another (e.g.: migrating from .NET core 3.1 to .NET 6) the question described here arises. These migrations are quite common in the industry and they are usually done in steps over the span of months. During this process there are .net core 3.1 applications and .net 6 applications which need to both reference one or more libraries depending on one or more Microsoft.Extensions.* packages.

[BillWagner]

adding @richlander

Thoughts on this idea?

[scharnyw]

Any update on this after more than a year? :)

An issue we sometimes meet is that there's some new functionality/bug fix in the latest Microsoft.Extensions.XXX that we would like to use, but our (ASP).NET Core programs are still stuck on a lower runtime version. I wonder if there's some concrete guideline on how to tell if this is safe from Microsoft?

[hdost]

I would like to mention that it's also something which because of confidence in library maintainers eyes its being cited as a reason to upgrade, but without any clear idea as a consumer of libraries it's not very confidence building. Related: open-telemetry/opentelemetry-dotnet#5277 (comment)

Also related open-telemetry/opentelemetry-dotnet#3448