Support net8.0 target in NuGet package about identitymodel

[josephdecock]

We do test against new versions of .NET as they are released, but I am reluctant to make a commitment that we would make new releases that multi target against each new release of .NET. All of the Microsoft maintained packages that were mentioned in this thread that do that are all on a synchronized release cadence, so it makes sense for them to be released together. In contrast, we make our own decisions about when to release, not tied to Microsoft's release calendar.

Microsoft's support policy also applies to those other packages, so I think maybe they are conveying their support by multi-targeting against those versions of the framework that they want to support. I see why, with all those Microsoft packages doing things that way, you'd get the vibe that packages should multi target all supported versions, but that isn't actually a universal or even particularly common practice for 3rd party packages. E.g., automapper, nunit, stackexhange.redis, and google.protobuff all are examples of actively maintained, very widely used packages that don't have a specific build for .NET 8.

And I think not needing a new build when there is an update is actually a good thing-stability and backward compatibility is good, and so by not making a particular version "the .NET 8 one", we avoid sending the message that if you want to use our stuff on .NET 8, you've gotta upgrade.

If there was a specific dependency problem that you could point to, and multi targeting would solve that problem, I'd be much more interested in multi-targeting. If you are running into a bad combination of dependencies, please share how that comes about - I definitely want to know about it!

Thanks for this though - we definitely want to "do the right thing", not contribute to dependency hell, and keep things working and stable.

[leastprivilege]

Why? Isn't the library backwards compatible?

[velocitysystems]

Why? Isn't the library backwards compatible?

It is. However it is fairly typical when a new version of .NET is released that all System dependencies in third-party packages are bumped to their respective dependencies i.e. 7.x, 8.x.

[leastprivilege]

Is it? Isn't that the job of the host to choose those versions? I am only expressing the minimum versions I require.

I would understand if there would be some sort of conditional compilation required between the .NET versions. Which does not seem to be the case...

Am I missing something?

[thohng]

Support multi Net Framework could be better than support the lowest Framework for compatiple. Keep the minimum version as compatible may not a good idea. These NuGet dependency change seems start from .NET 7.0.
For example:

• Runtime library 7.0 will support both net7.0, net6.0, netstardard2.0

• Runtime library 8.0 so far support both net8.0, net7.0, net6.0, netstardard2.0
  https://www.nuget.org/packages/System.Text.Encodings.Web/7.0.0#dependencies-body-tab
  https://www.nuget.org/packages/System.Text.Encodings.Web/8.0.0#dependencies-body-tab
  https://www.nuget.org/packages/Microsoft.Extensions.Logging/7.0.0#dependencies-body-tab
  https://www.nuget.org/packages/Microsoft.Extensions.Logging/8.0.0#dependencies-body-tab

• AspNetCore library 7.0 will not compatible with net6.0 and net8.0
  https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.Google/7.0.0#dependencies-body-tab
  https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.Google/8.0.0#dependencies-body-tab

• EFCore library 7.0 will compatible with net6.0, but EFCore library v8.0 not compatible with 7.0
  https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/7.0.0#dependencies-body-tab
  https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/8.0.0#dependencies-body-tab

This is from System.Text.Json 8.0

[leastprivilege]

Will re-visit once net6 goes out of support.

[nuttytree]

I think this decision should be reconsidered, in general a NuGet should be targeting all currently supported versions of .NET because it gives consumers of the NuGet confidence that the code has been evaluated and tested against the newer versions of .NET, so that any changes in the newer versions of .NET can be accounted for, and to ensure consistent versions of dependencies like System.Text.Json.