I fully support this decision, it was already great to keep compatibility with .NET Framework for such a long time!

The impact on supported TFMs for Npgsql 9.0 is not clear for me, in particular for packages currently supporting netstandard2.0 like some Npgsql.* plugins, do they move to netstandard2.1?

@manandre netstandard2.1 supports only .NET Core 3.0 and above (and no .NET Framework at all, see table); given that the oldest .NET Core TFM that's supported is net6.0, netstandard2.1 is kinda dead.

So the plan would be for Npgsql 9.0 to target net6.0 as its minimum TFM. The Npgsql plugins which are maintained in our repo would also be updated to target net6.0 as the minimum, others would need to update as well.

@roji Does this table correctly sum up the targeted setup?

Given that Npgsql 9 will probably appear after November 12, 2024, maybe we should align with the official .NET support policy and already drop net6.0.
I know that net6.0 currently causes very little maintenance burden, but that will occur at some point and I see a big pro in having a predictable support policy.

@manandre given that net7.0 goes out of support in May of 2024 and Npgsql 9.0 will be released in October, I don't think we'll be targeting net7.0. But otherwise that looks more or less right.

@Brar yeah, technically we could drop net6.0 as well for 9.0. As net6.0 will go out of support exactly when we release Npgsql 9, I think it would be helpful to support it for one more year, giving users a bit more time to upgrade; but I don't have super strong feelings about it...

(It's already such a relief to get rid of netstandard2.0 and the old stuff that keeping net6.0 for a year seems like no effort at all 😅 )

What I have in mind that we typically not only support the current Npgsql release, but rather also the two previous ones.
So dropping it with Npgsql 10 in 2025 would make us install the long unsupported net6.0 for maintenance purposes until 2027 in order to be able to backpatch and test things for Npgsql 9.
Also I don't see the point in upgrading Npgsql to the newest release (given we still maintain the older ones too) while staying on an out of support version of .NET.

Yeah, we'll certainly have some unsupported TFMs in CI for previously-released versions for patching, but that seems pretty harmless no?

Also I don't see the point in upgrading Npgsql to the newest release (given we still maintain the older ones too) while staying on an out of support version of .NET.

Maybe, but we know lots of people do that... They may urgently need a feature or bug fix from the new Npgsql version, but don't have the time right away to upgrade and test the new .NET version, for example.

I'm not really pushing back that much - we can see what the other Npgsql folks think. It's just that keeping net6.0 for another year will likely add no burden on us, is all.

Let's start with this setup, we may adapt later if needed.

@manandre assuming we keep net6.0 for Npgsql, Npgsql.DependencyInjection should also keep working on net6.0.

Oh you are right! New attempt:

Are you planning on maintaining Npgsql 8.x for as long as Microsoft supports .NET Framework? As far as I know, there is no EOL for .NET Framework specified. It is supposed to be supported for as long as it's included in Windows.

@jemiller0 we'll probably maintain Npgsql 8.x for quite a while, since it's indeed the last version to support .NET Framework; that means security and critical bug fixes. But there's definitely no commitment to do that for as long as Microsoft supports .NET Framework; this is an open-source, volunteer-based project, and at some point the ecosystem does need to move on to modern .NET.

OK, thanks. I suspect that there are a lot of ASP.NET Web Forms apps out there that won't be upgraded anytime soon that will need it. Too bad Microsoft threw Web Forms under the bus and didn't move it forward onto .NET.

@jemiller0 yep, for sure - these will have to stay on an old version of Npgsql (8.0), and will no longer benefit from new features/improvements etc.