rabbitmq-dotnet-client
rabbitmq-dotnet-client copied to clipboard
rabbitmq
Discussion: Supported frameworks
I've created a separate issue for the discussion about the supported frameworks originating in #857 Copied the last response from @danielmarbach
Considering that .NET Framework will probably not see any updates except for security updates, and that MS is pushing full force for .NET 5 as it's next release, my personal opinion is that 7.0 should target .NET Standard 2.1, and 6.X should be the last .NET Framework supported release. This is of course always a debatable thing, but given that for example some C# 8.0 language features can only be used in .NET Core it's obvious that .NET Framework is just on life support until it's support lifetime runs out, it seems like a good cutoff point to leave behind legacy code and move the codebase forward.
At that point it'd make sense to create a separate 6.X branch for reliability/security updates and possibly minor features.
what is the benefit of targeting .NET Standard 2.1? As it stands my understanding is that .NET Standard 2.1 is basically more or less a dead end. With the introduction of .NET 5 the standards have been merged into .NET 5 TFM. But that being said .NET 5 will not even be the LTS version. Only .NET 6 will be the LTS version. So from a consumer perspective nobody but bleeding edge contributors really care in what language version the rabbitmq client is written or do they?
I would guess from a Pivotal / VMWare perspective given the broad adoption of the rabbitmq client having a broader set of compatibility makes more sense instead of too early corner the client in "just because performance" (of course this is drastically and potentially unfairly simplified for the sake of my argument ;) ). Yes .NET 4.8 is basically the last version and only .NET 4.7.2 and higher properly supports .NET Standard 2.0. Even though .NET Standard 2.0 is a little bit of a disaster and the System packages used can cause headaches and don't offer the true perf one would expect (and sometimes even cause binding redirect issues) wouldn't it from an adoption perspective as well as long tail perspective make sense to stay a bit longer on the .NET Standard 2.0 train (with or without dual targeting to .NET Framework)?
As @stebet said in his comment:
My full-async PR (which I'm hoping to submit for your review in the next few days) targets only .NET Standard 2.1 and the latest .NET Core LTS version (3.1) is already .NET Standard 2.1 ready.
I'd assume some of the functionality requires NS2.1.
As for me, there are certain methods that simplify things or have better performance in NS 2.1. AFAIK most of them do have some kind of workaround for NS2.0. If this holds true, then I'd suggest to have a dual framwork targeting for NS 2.0 and NS 2.1 (for the clients which go with the newer .NET)
My biggest reason for going with NS2.1 was the "Span"ification of the BCL. I can certainly look into the amount of work required to get my Async-branch to compile under NS2.0 as I agree that the jump to NS2.1 (and ultimately 5) is hefty. Do note though that .NET Core 3.1 supports NS2.1, so it is targeting the latest LTS release.
@michaelklishin @lukebakken @stebet @bording @bollhals FYI I'm going on vacation end of this week and will be mostly disconnected to recharge. I would love though to have the conversation about the framework as well as the async changes at some point potentially in a meeting and then summarize the thoughts together on the various issues here in the repository. I don't want to imply I'm required should you wish to do that while I'm away. Happy to also catch up async or said be part of the meeting should you wish my input.
No worries @danielmarbach I've been too busy with other RMQ related work to do much with this library recently.
I'll be out next week. I haven't forgotten, but it's PTO season these days :smile:
#971 has changed the targetframework to .net standard 2.0 & .net core 3.1 for now. => NS 2.1 doesn't make much sense, as only .net core 3.0+ implements it, which is already end of support.
Only question is whether we want to drop NS 2.0 as well or not. (Depending on how much work it will be to continue supporting NS2.0 with the new async features.
Only question is whether we want to drop NS 2.0 as well or not. (Depending on how much work it will be to continue supporting NS2.0 with the new async features.
Async is well doable in NS2.0 with minimal effort.
Version 7.x of this library will include netstandard2.0 as a target framework. Please see the following issue for discussion around version 8 and beyond:
https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/1424