Update targetframeworks for all Grpc.* packages

[jskeet]

As agreed in internal discussions, suggested new TFMs are:

• netstandard2.0
• net462
• net6.0 if it provides benefits

[jtattermusch]

My only concern is the Grpc.Core.Api package (which is supposed to continue working with the legacy Grpc.Core releases).

What would we gain by updating the targetframeworks for Grpc.Core.Api (as opposed to just updating Grpc.Auth which is the original reason why this is requested) and doesn't the risk outweigh the gains? I'm happy to be convinced that this change is safe, but I really don't want to break Grpc.Core users with this optional change.

CC @apolcyn @tonydnewell

grpc-dotnet/src/Grpc.Core.Api/Grpc.Core.Api.csproj

Line 8 in 40a26c9

<TargetFrameworks>net462;netstandard1.5;netstandard2.0;netstandard2.1</TargetFrameworks>

[jskeet]

It would probably be worth evaluating what situations would be broken by this. By my reckoning, which could be wrong, someone would have to:

• Have dependencies on both Grpc.Core and Grpc.Core.Api with different versions (if they've only got Grpc.Core, then that would presumably use the Grpc.Core.Api version that Grpc.Core depends on)
• Be targeting a long-unsupported platform (e.g. net45 or .NET Core 1.x)

I think it's reasonable to not support that scenario - but if there's a scenario which we think we should still support which would be broken by this, then sure, just changing Grpc.Auth would still unblock the Google client libraries team.

[jtattermusch]

It would probably be worth evaluating what situations would be broken by this. By my reckoning, which could be wrong, someone would have to:

• Have dependencies on both Grpc.Core and Grpc.Core.Api with different versions (if they've only got Grpc.Core, then that would presumably use the Grpc.Core.Api version that Grpc.Core depends on)

I think a reasonable scenario is to have the latest Grpc.Core.Api (e.g. because there was a backward-compatible fix in the API or some of the helpers contained in Grpc.Core.Api and you want to benefit from having a patched version of Grpc.Core.Api) and the latest version of Grpc.Core (which always starts with 2.46.x these days as there are no newer versions of it). So you can have Grpc.Core.Api 2.57.0 (Grpc.Core.Api still gets new releases) together with Grpc.Core 2.46.6 and they should still work together well.

• Be targeting a long-unsupported platform (e.g. net45 or .NET Core 1.x)

I think it's reasonable to not support that scenario - but if there's a scenario which we think we should still support which would be broken by this, then sure, just changing Grpc.Auth would still unblock the Google client libraries team.

[JamesNK]

My only concern is the Grpc.Core.Api package (which is supposed to continue working with the legacy Grpc.Core releases).

I investigated this and had some interesting findings. The scenario of an incompatibility between Grpc.Core and modern Grpc.Core.Api already exists today!

• Grpc.Core.Api targets net462, netstandard1.5, netstandard2.0, netstandard2.1.
• Grpc.Core targets net45, netstandard1.5 and netstandard2.0.

Someone using Grpc.Core on net45, net451, net452 and net46 can't use the latest Grpc.Core.Api. This scenario has existed for at least a year. The positive here is no one has raised this as a problem.

If we dropped netstandard1.5, then new platform incompatibilities would be .NET Core 1.0, .NET Core 1.1, and Tizen 3.0 (from 2017). I don't know about Tizen, but .NET Core 1.x is very out of support.

[jtattermusch]

My only concern is the Grpc.Core.Api package (which is supposed to continue working with the legacy Grpc.Core releases).

I investigated this and had some interesting findings. The scenario of an incompatibility between Grpc.Core and modern Grpc.Core.Api already exists today!

• Grpc.Core.Api targets net462, netstandard1.5, netstandard2.0, netstandard2.1.
• Grpc.Core targets net45, netstandard1.5 and netstandard2.0.

Someone using Grpc.Core on net45, net451, net452 and net46 can't use the latest Grpc.Core.Api. This scenario has existed for at least a year. The positive here is no one has raised this as a problem.

If we dropped netstandard1.5, then new platform incompatibilities would be .NET Core 1.0, .NET Core 1.1, and Tizen 3.0 (from 2017). I don't know about Tizen, but .NET Core 1.x is very out of support.

That seems fair. I think we can proceed with the change.