Drop NET 4.0 support for Npgsql 3.0 - it will not be supported by MS after 1/1/2016

[dekrr]

If I understand correctly, you are planning to support .NET 4.0 with the next version Npgssql 3.0. However, Microsoft will end support for it in January 2016. So it makes no sense to support this old version of .NET Framework and it's better to start with .NET 4.5.2. If someone needs 4.0 - they can just use Npgsql 2.2 - it even works with async keyword (simulated)

[roji]

https://support.microsoft.com/en-us/gp/framework_faq/en-us

I tend to agree with this. Since we last discussed this some time has passed, and v3 will represent a serious (and potentially breaking) upgrade for users anyway - so it seems to make sense to require .NET 4.5 as well.

@Emill, @franciscojunior, other people, any comment?

@Emill it would solve the issue we have with SemaphoreSlim :)

[AEMPhil]

Gentlemen,

I don't think I have contributed to any discussions here in a while, but I thought I'd chime in on this one.
The referenced article does point out that the .Net3.5 line has its own lifecycle. It remains an important part of server environments. This implies to me that dropping support for 4.0 in favor of 4.5.2 is certainly fine, but I would hope the 3.5SP1 line would not be forgotten.
I certainly understand the argument that people could stick to 2.2, but lurking around this list over the past few months has shown that a number of issues on that line have not been fixed, often in favor of suggesting that individuals try the new improvements in the 3.0 branch, or recommending patience until that version comes out. If support for anything below 4.5.2 is dropped in 3.0, then 2.2 should probably be viewed as a project that will need some maintenance for the foreseeable future, with a number of features backported there.
Not having contributed any code to the project, I do realize my opinion may not carry much weight, and rightfully so, but I wanted to share the perspective of an individual who has to manage and maintain applications both old and new.

As always, with thanks for all your good work,
Philippe

On Apr 7, 2015, at 05:26, Shay Rojansky notifications@github.com wrote:

https://support.microsoft.com/en-us/gp/framework_faq/en-us

I tend to agree with this. Since we last discussed this some time has passed, and v3 will represent a serious (and potentially breaking) upgrade for users anyway - so it seems to make sense to require .NET 4.5 as well.

@Emill, @franciscojunior, other people, any comment?

@Emill it would solve the issue we have with SemaphoreSlim :)

—
Reply to this email directly or view it on GitHub.

[dekrr]

I think it's much easier to provide a few fixes for most critical issues for 2.2 than make 3.0 compatible with .NET 4. Also consider that stuff like async can be made much easier in 4.5 than in previous versions.

[franciscojunior]

From the documentation, it seems that any .net 4.0 installation should be updated to 4.5.2. So, in this case, I think we could safely drop support for 4.0 and concentrate only on 4.5.2 onwards in 3.0 branch.

At the same time, @AEMPhil has some interesting points. We would need to check our tong term strategy about 2.2 branch. Unfortunately, today we can't say exactly how many people are using 2.2 and are stuck in the .net 3.5 framework without the possibility of upgrading. I think we will have a better idea when we release the 3.0 when people start using it and only those who really can't update would tell us, just like @AEMPhil is calling our attention.

I think we could start our kind of survey with @AEMPhil. :)

@AEMPhil , today, what are the main problems you see with 2.2 version regarding non ported features? Is the system using 2.2 version not able to be upgraded to use 3.0? Are you stuck with the 3.5sp1? If so, are you adding more features to your program which would need the new features of Npgsql, or are you thinking simply about fixes?

Thank you in advance for all your help.

[AEMPhil]

The real issue is indeed when the system constrains use of 3.5, or the 2.0 line in general. I have a case where I build plugins for a platform that has not made the move to the 4.0 line yet. For those, I have an outside constraint that keeps me on the 3.5SP1 track for at least the next 18 months.
Large architectures that heavily rely on legacy COM components might hit the same roadblock.

I am thinking only about fixes in the 2.x branch. The key is that if support for .Net 3.5 is dropped from Npgsql 3.0, then saying that the problem is fixed there is no longer a valid way of addressing a bug report since the user may not be able to upgrade.

On Apr 7, 2015, at 11:03, Francisco Figueiredo Jr. notifications@github.com wrote:

From the documentation, it seems that any .net 4.0 installation should be updated to 4.5.2. So, in this case, I think we could safely drop support for 4.0 and concentrate only on 4.5.2 onwards in 3.0 branch.

At the same time, @AEMPhil has some interesting points. We would need to check our tong term strategy about 2.2 branch. Unfortunately, today we can't say exactly how many people are using 2.2 and are stuck in the .net 3.5 framework without the possibility of upgrading. I think we will have a better idea when we release the 3.0 when people start using it and only those who really can't update would tell us, just like @AEMPhil is calling our attention.

I think we could start our kind of survey with @AEMPhil. :)

@AEMPhil , today, what are the main problems you see with 2.2 version regarding non ported features? Is the system using 2.2 version not able to be upgraded to use 3.0? Are you stuck with the 3.5sp1? If so, are you adding more features to your program which would need the new features of Npgsql, or are you thinking simply about fixes?

Thank you in advance for all your help.

—
Reply to this email directly or view it on GitHub.

[roji]

Hey @AEMPhil, thanks for your voice on this.

One problem we have, as @franciscojunior said, is that we have almost no info as to Npgsql users and their .NET framework needs. So we have no idea how many people are in the situation you describe, i.e. unable to upgrade from .NET 3.5. At some point I tried to post a question in our help forum and got no responses.

Another note is that we discussed dropping .NET 3.5 (and 2.0) a while ago (see #320), and this change has already been done in Npgsql v3. This issue is about dropping .NET 4.0 as well. However, you're right that dropping .NET 4.0 seems to be a much easier decision than dropping .NET 3.5, since that is Microsoft's policy as well.

Now to the actual question... I think that actually maintaining 2.2 until the end-of-life of .NET 3.5 is unfortunately out of the question... We're a (very) small team and maintaining two major versions of Npgsql doesn't seem realistic. This leaves the option of continuing to support .NET 3.5 in Npgsql v3. While this is definitely possible, supporting old frameworks adds a "tax" to everything we develop - we can't use newer features. One example is that v3 isn't currently compiling on .NET 4.0 because of the lack of the SemaphoreSlim class. The issue is of course more severe with .NET 3.5 which is much older.

I guess one thing we could do is attempt to compile v3 with .NET 3.5 and see how serious the problems are. If .NET 3.5 isn't the end of the world we can do it, but if it implies a lot of work I'm not sure what the options are.

[AEMPhil]

Sorry I missed the earlier discussion on dropping 3.5. No need to revisit past decisions.

I know you guys are a small team, in spite of which you do a great job. I hope I didn't stir up any animosity.

As far as the 4.x line is concerned, all my new development is already at 4.5+, so dropping 4.0 support would be cause no trouble to me.

On Apr 9, 2015, at 00:40, Shay Rojansky notifications@github.com wrote:

Hey @AEMPhil, thanks for your voice on this.

One problem we have, as @franciscojunior said, is that we have almost no info as to Npgsql users and their .NET framework needs. So we have no idea how many people are in the situation you describe, i.e. unable to upgrade from .NET 3.5. At some point I tried to post a question in our help forum and got no responses.

Another note is that we discussed dropping .NET 3.5 (and 2.0) a while ago (see #320), and this change has already been done in Npgsql v3. This issue is about dropping .NET 4.0 as well. However, you're right that dropping .NET 4.0 seems to be a much easier decision than dropping .NET 3.5, since that is Microsoft's policy as well.

Now to the actual question... I think that actually maintaining 2.2 until the end-of-life of .NET 3.5 is unfortunately out of the question... We're a (very) small team and maintaining two major versions of Npgsql doesn't seem realistic. This leaves the option of continuing to support .NET 3.5 in Npgsql v3. While this is definitely possible, supporting old frameworks adds a "tax" to everything we develop - we can't use newer features. One example is that v3 isn't currently compiling on .NET 4.0 because of the lack of the SemaphoreSlim class. The issue is of course more severe with .NET 3.5 which is much older.

I guess one thing we could do is attempt to compile v3 with .NET 3.5 and see how serious the problems are. If .NET 3.5 isn't the end of the world we can do it, but if it implies a lot of work I'm not sure what the options are.

—
Reply to this email directly or view it on GitHub.

[CezarCretu]

[I have no 3.5 projects and I'm not a contributor to this repository, however:]
Regarding .NET 3.5, there's also the option of dropping support for it in v3 ofically and letting those that use it backport any features to the v2.2 branch themselves (if they are interested).
That would still add some overhead for you since it means there's code to review and releases to manage, but it seems a lot less severe than continuing to support an 8-year-old framework.

I would also say that keeping support for .NET 3.5 in master not only makes it harder on you guys, but it might also be an additional barrier to entry to any new contributors, since no one really enjoys legacy software.

[roji]

@AEMPhil no animosity at all! It's also totally fine to reopen the previous "decision" to drop .NET 3.5 if we need to.

@CezarCretu, you're right, of course once we release v3 updates to the 2.2 branch can still happen, and we can continue to accept PRs from the community. The problem is that we'd have to review those PRs, and it seems that in general we get more issue reports than PRs...

[CezarCretu]

Sure, and the official stance on those issues could be that the v2 branch is no longer supported, so at that point it's either upgrade or fix it yourself.

After all, let's take it for what it really is. It seems plausible that many, if not all, of the remaining .NET 3.5 installs only exist due to a business decision, cost vs benefit. While that's fair and maybe even wise in many cases, what's not fair is expecting others to support that decision for free.

It might be annoying for the developers stuck using 3.5, as they probably have no say in the matter, but there's no free lunch and the costs of legacy software should be supported by the organizations that use it themselves.

And the same reasoning applies for .NET 4.0, but that's even worse: it's an in-place upgrade and there aren't a whole lot of reasons to keep it or costs associated with upgrading.

As an aside, your commercial competitor supports all .NET versions starting with 2.0, so it's not like there aren't alternatives for legacy projects.

[roji]

So let's do the following... For now we'll build v3 for .NET 4.5. When the version is almost down I'll take a look at what it would take to build for .NET 3.5. If it's really not that big a deal, we can do it. Otherwise we'll drop it and support .NET 4.5 only.

[mikkeljohnsen]

Mono has also dropped support in 4.0.0

"We dropped support for the 2.0, 3.5 and 4.0 assemblies"

[yallie]

Hello, sorry to revive this old thread.
.NET 4.0 is the last .NET version available on Windows XP.
Unfortunately, XP is still widely used (ATMs, payment terminals, etc).

Does Npgsql use anything strictly .NET 4.5-specific?
Is it possible to backport it to .NET 4.0 or we're stuck with 2.x branch?

[roji]

I feel your pain... One main issue is the use of async methods, although it may be possible to work around this. Another example is Npgsql 3.2 switching to use Microsoft.Extensions.Logging for its logging (#1184), but that package isn't available for .NET 4.0.

There just hasn't been that much demand for .NET 4.0 support, and adding it would seriously constrain what we can do going going forward...

Out of curiosity, is anyone using Npgsql on ATMs or payment terminals?

[yallie]

Thanks for the clarification!

There just hasn't been that much demand for .NET 4.0 support, and adding it would seriously constrain what we can do going going forward...

Yes, I understand that. Was thinking about forking a stripped-down version for the sake of .NET 4.0 support.

Out of curiosity, is anyone using Npgsql on ATMs or payment terminals?

Not sure about Npgsql, but the linq provider library is used on many XP machines and is stuck with .NET 4.0.

[roji]

Yes, I understand that. Was thinking about forking a stripped-down version for the sake of .NET 4.0 support.

You may be able to get away with it, while retaining most of the functionality. I'd definitely be interested in learning how that goes. Try to make async work via Microsoft.Bcl.Async, and then see where the hurdles are. If you get to a reasonable result without stripping essential stuff I may merge your work.

Not sure about Npgsql, but the linq provider library is used on many XP machines and is stuck with .NET 4.0.

Yeah, it's much easier to stay on .NET 4.0 when your library exclusively deals with objects in memory etc. When you start doing I/O and using system APIs things get more difficult.

[yallie]

Thanks roji, will think about it!