Dropping .NET 4.8 support

[cincuranet]

Is year 2024 year for dropping .NET 4.8 support?

There's multiple reasons why it would be nice. The codebase would be simpler and also allow use of "modern" .NET and C# features simplifying and cleaning the codebase even more. Together with that goes the (performance) features. And many more. I think we're all aware - on some level - of the benefits.

But I'd like to hear reasons why not to drop .NET 4.8? Why keep it?

[cincuranet]

At the moment I tend to think that netcoreapp3.1/netstandard2.1 could be the minimum supported versions.

[PeterAdam]

Why not? Because the .net framework is the full, working, not dumbed down .net* staying with us while Windows exists. Who needs to touch everything in 2-3 years to be supported just to make the Cool Kids On The Code Block happy?

• Do anything serious and you need the abandoned parts: local reporting, workflow, communications foundations. There is no code access security, can't kick out something from an AppDomain, ... Everything dumbed down to Unix level. Don't let me start on the capabilities of the portable PowerShell on Windows ...

[bauradar]

If .netstandard 2.0 (not only 2.1) will be support, net 4.8 could use the provider. Even when developers are on the way to core, it takes time and there are still a significant number of 4.8 apps out there.
I support the plan to clean up. A version to be used with .net 4.8 is still neccessary from my point of view.

[krilbe]

While I agree there's a need to have a version that supports .NET Standard 2.0 (and thus .NET Framewrok 4.x), I'm not sure that this backwards compatible version really needs to keep receiving new features. In other words I suggest to decide that major version X will drop .NET Standard 2.0 and .NET Framework, but keep version (X-1) published on NuGet and for some limited time do try to maintain it with serious bug fixes if any. People who need new features will have to migrate to .NET 5+ or something. If you need to stay at .NET Framework, then you need to stay at version X-1 and only receive bugfixes.

[mrjohnr]

+1 to keep it as MS will support it
99% we are developing winforms.not a easy way to migrate winforms to .net core

[anli-xsigns]

+1 to keep too, we're developing a winforms application too and it's a huge amount of work to migrate

[Ionut27]

+1 for keep it,winforms too

[snaidamast]

Hello Jiri...

Why not separate out the provider between one that will continue to support the standard .NET Frameworks up through 4.8.x and one that will support .NET Core 5.x through 8.x?

This way, the major upgrades can continue to the .NET Core version without concern for anything affecting the version for the standard .NET Frameworks. When you believe an update is required for this version then it can be accomplished without any concern for the one that supports the .NET Core versions.

It is true that you would have multiple code bases but then by separating out the providers, you will not have the problem of any conflicts between the support for both types of .NET Frameworks.

Considering that the .NET Core Frameworks would not be considered "mature" with all the constant upgrades, many of us are still working with the standard .NET Frameworks because they are more stable and for what many of us do, are perfectly workable for our endeavors.

If this wasn't the case then the question here wouldn't need to be asked...

Steve Naidamast
Sr. Software Engineer

[stefanhapp]

+1 for keep
We developing Pos Apps with opos hardware like Epson, Diebold, IBM, Datalogic and much more and they still use .net 4.8 in Windows application. Indispensable for us.

Stefan

[krilbe]

A question for all of you who vote to keep FW 4.8 support: Is it necessary to keep providing new features for you and your platform? Or would it suffice to just maintain the current latest version with bug fixes for a limited period of time and then just freeze it? I mean, the existing versions that support FW 4.8 won't disappear because new major versions drop that part, right?

And for you @cincuranet, would it be a good solution to drop FW 4.8 support moving forward (next major version), but maintain bugfix support for the current latest major version for a limited period of time?

For how long would the community need such bugfix support?

I would probably suggest to have a vote for which features to implement, if any, before freezing the feature set for the legacy FW 4.8 supporting major version. When those features are implemented, freeze that feature set and then, when starting work on next major version drop FW 4.8 support at that point.

Make sense?

[bauradar]

It would be great to keep 4.8 or .net Standard 2.0 with the current and ongoing bugfixes, features etc.

BUT: We are asking here Jiri do deliver software service - just for free. Yes, I know that Firebird is an open source project. Having said that: I assume that Jiri (or other Firebird and Firebird .net Provider) developers have to pay their bills.

If the support for 4.8 or .net standard 2.0 would be droppend it might be no problem on the short run: We stick to the latest version 10 of the .net provider. In the case an issue pops up it would not be fixed as part of the ongoing product maintaince delivered by Jiri.

Long story short: What can we as .net provider 4.8 (or .net Standard 2.0) consumers do to keep it maintained? Is there a funding we should set up?