search

StackExchange / StackExchange.Redis

General purpose redis client
https://stackexchange.github.io/StackExchange.Redis/
Other
5.88k stars 1.51k forks source link

.Net 8.0 version support #2770

Open askids opened 1 month ago

askids commented 1 month ago

hi,

Is there a plan to publish this library built on .Net 8? For both .Net Core 3.1 and .Net 6, it was published within few months after those LTS versions came out. But for .Net 8, I dont see a version released yet. I understand that .Net standard 2.0 version will work with .Net 8.0. But is there a reason why the .Net 8 based version is not yet released for this library?

Thanks!

mgravell commented 1 month ago

The net6 version is fine for net8. The only reason to add an additional TFM here would be to utilize an additional API not available in net6; without that: there is zero benefit in adding a net8 target - and adding such would increase the download size etc.

So: other than "because net8 exists" (which isn't a sufficient reason): is there a reason to add an explicit net8 target?

askids commented 1 month ago

So: other than "because net8 exists" (which isn't a sufficient reason): is there a reason to add an explicit net8 target?

Mostly red tape and rigid processes beyond our control as developer :) Our problem is that .Net 6 reaches EOL in Nov and we have to complete upgrade to .Net 8 of multiple components across multiple applications which are dependent on this library. So the upgrade work will have to be planned and completed in next couple of months to release changes to production before EOL date. Else our apps will get flagged for running non permitted technology (any deemed as having reached EOL and not receiving any security patches). Plus with this specific client library, we have previously run into issue, when version upgrade was done on our end with minimal testing and in this case, we would have been catching up with multiple versions of update that has happened, since our last upgrade. So we typically want to plan the upgrade work such that it aligns with some planned project release, where app will undergo sufficient rounds of regression testing, LLE use and app performance testing, allowing us to catch any issues. So having the .Net 8 supported version now will allow us to go ahead with the plan and complete the work and plan for production release before Nov.

In general, shouldn't such standard libraries used by thousands of developers be adding support for .Net LTS versions? I can understand not releasing support for non-LTS version due to its short shelf life. Download size increasing seems like a poor excuse.

NickCraver commented 1 month ago

In general, shouldn't such standard libraries used by thousands of developers be adding support for .Net LTS versions? I can understand not releasing support for non-LTS version due to its short shelf life. Download size increasing seems like a poor excuse.

No, because that's not how libraries and APIs work in .NET. It's not an excuse, it's us saying "there's no reason to add that build - it adds zero value". We do support .NET 8 already, there's nothing to do. .NET has an API surface area we call. That surface area hasn't changed.

Think about the alternative, the way you're seeming to understand it at the moment: it would mean every library everywhere has to add support for every version on a treadmill and every library that exists would by default become useless if action was not taken. This is simply not the case and not how .NET is designed. net6.0 libraries work perfectly fine in net8.0 unless there's a breaking change they have to account for. We have no breaking changes to account for, so we don't need to add net8.0 target.