MySqlConnector icon indicating copy to clipboard operation
MySqlConnector copied to clipboard

Drop support for netstandard1.3, net45, net461?

Open bgrainger opened this issue 5 years ago • 20 comments

To simplify the library (removing ifdefs), reduce package size, and possibly enable new features (e.g., pipelines, Utf8String?) remove support for the following platforms:

  • netstandard1.3
  • .NET 4.5.x
  • .NET 4.6.x

Should the minimum .NET Framework version be updated to 4.8, or stay at 4.7.1? Or dropped entirely?

Right now System.IO.Pipelines still supports netstandard1.3, so dropping old platforms may not strictly be necessary.

This is also a current advantage of MySqlConnector over MySql.Data: we support netstandard1.3 (vs netstandard2.0) and net45 (vs net452).

bgrainger avatar May 11 '19 20:05 bgrainger

FYI Npgsql is dropping net45 but is retaining support for net461, mainly because for now there's nothing we seem to need urgently that would require us to drop that as well. ifdefs seem at quite tolerable levels at least for now.

roji avatar May 23 '19 11:05 roji

See previous discussion in #506.

bgrainger avatar Jun 18 '19 04:06 bgrainger

.NET Core 1.x support ended today: https://dotnet.microsoft.com/platform/support/policy/dotnet-core

bgrainger avatar Jun 27 '19 23:06 bgrainger

This is also a current advantage of MySqlConnector over MySql.Data: we support netstandard1.3 (vs netstandard1.6) and net45 (vs net452).

As of MySql.Data 8.0.18, netstandard1.6 has been dropped.

bgrainger avatar Oct 14 '19 17:10 bgrainger

.NET 4.5.1 and older is not supported by MS, thus references could be removed.

.NET 4.5.2 and 4.6 should be supported about the same as framework itself.

From: https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework

.NET Framework 4.5.2: Support for .NET 4.5.2 follows the lifecycle policy of the parent OS. It is supported as a Windows component on the latest required operating system update for Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, and Windows Server 2012 R2.

.NET Framework 4.6: Support for .NET 4.6 follows the Lifecycle Policy of the parent OS. It is supported as a Windows component on the latest required operating system update for Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, Windows Server 2012 R2, and Windows 10.

Many software companies sync to above lifecycle with their products, I think this project should too.

SylwesterZarebski avatar Dec 11 '19 14:12 SylwesterZarebski

As this issue is quite old, what's the current stance on this? I believe given the time that netstandard2.0 has been around and successful, is now the right time to drop anything that doesn't support it?

I believe netstandard2.0 and net461 should be the baseline of supported frameworks. I would be willing to submit a PR if we reach consensus.

ViktorHofer avatar Apr 21 '21 21:04 ViktorHofer

From https://github.com/mysql-net/MySqlConnector/issues/972:

I would suggest to consider dropping support for .NET Standard 1.3 and older .NET Framework versions in favor of a broader API set and a simplified dependency graph.

Other than slightly more complex code (#ifdefs) and a larger NuGet package download size, I don't think it's "hurting" anyone to keep netstandard1.3 support. Is there any particular urgency to drop older frameworks?

It would be super helpful if NuGet would show the number of downloads for each target framework so we could evaluate the need to support each one: https://github.com/NuGet/NuGetGallery/issues/3450

bgrainger avatar Apr 21 '21 21:04 bgrainger

Note that MySqlConnector is eagerly adopting new framework features (e.g., ZLibStream in .NET 6: https://github.com/mysql-net/MySqlConnector/commit/1a20890c3ecd8d9d9842caa9a69e5402aa723c72) and this is not prevented by also supporting older frameworks. (Using the new preprocessor definitions (https://github.com/mysql-net/MySqlConnector/commit/a0a14ef938ff1132e2c4579da188555f0b839d63) makes this reasonably easy to do.)

bgrainger avatar Apr 21 '21 21:04 bgrainger

My current thinking is that the 1.x series will continue supporting the current TFMs and that reducing TFM support (perhaps even as drastically to just net6.0 based on the current .NET LTS versions) would be a breaking change (others TBD) in a 2.0 release.

bgrainger avatar Apr 21 '21 21:04 bgrainger

@ViktorHofer Are you able to provide any internal support within Microsoft for https://github.com/NuGet/NuGetGallery/issues/3450?

As this comment https://github.com/NuGet/NuGetGallery/issues/3450#issuecomment-372510244 indicates, it would be extremely useful for NuGet Package owners.

bgrainger avatar Apr 21 '21 21:04 bgrainger

Other than slightly more complex code (#ifdefs) and a larger NuGet package download size, I don't think it's "hurting" anyone to keep netstandard1.3 support. Is there any particular urgency to drop older frameworks?

It's great to hear that MySqlConnector already adopts newest framework features 🎉. I don't think there is a strong reason to drop older frameworks. That said, doing so would simplify the dependency graph, the test matrix (netstandard1.3 applies to many platforms which would ideally be tested on/for) and to convey the message that the repo doesn't target frameworks which are out of support (which might help in the long run).

It would be super helpful if NuGet would show the number of downloads for each target framework so we could evaluate the need to support each one: NuGet/NuGetGallery#3450

Absolutely agree.

@ViktorHofer Are you able to provide any internal support within Microsoft for NuGet/NuGetGallery#3450?

I would love to be able to help here. The NuGet team knows about the feature request and honestly speaking, we ourselves would have benefited of such statistics immensely already. Unfortunately there is nothing in my power to prioritize the item higher.

ViktorHofer avatar Apr 21 '21 21:04 ViktorHofer

I think I see a trend here... any particular reason why this is an important issue for MySqlConnector?

From the other thread. When .NET Standard 2.0 was added to .NET a few years ago, I contributed to various open source libraries to add support for it. Now that time has passed I feel like the .NET ecosystem would benefit again from such a change, but this time the other way around, by cleaning up packages' dependency graph.

Anytime, a package which targets .NET Standard < 2.0 is restored, all the transitive dependencies of the NETStandard.Library package are restored as well. Many of the packages that NETStandard.Library itself relies on, don't get updates anymore as those aren't built live anymore. Instead they are re-distributed from older packages into newer ones.

As an example take a big open source repository like xunit which decided to stop supporting .NET Framework < 4.8, .NET Standard < 2.0 and .NET Core < 2.1. I personally think that it's valuable for the ecosystem to evolve and focus on supported frameworks and platforms.

ViktorHofer avatar Apr 21 '21 22:04 ViktorHofer

A few comments here too...

As a contributor to various open source projects, I become hesitate to contribute when the projects support a large number of targets where changes risk breaking a legacy runtime.

Dropping .NETSTANDARD1.3 minimizes the risk as a contributor triggering a platform specific bug that no-longer receives updates -- and unintentionally breaking another users applications.

It also helps improve the health of the .NET ecosystem by getting these users to upgrade to a modern and supported runtime.

iamcarbon avatar Apr 21 '21 22:04 iamcarbon

Anytime, a package which targets .NET Standard < 2.0 is restored, all the transitive dependencies of the NETStandard.Library package are restored as well.

To clarify: if I install MySqlConnector into a net5.0 application, the transitive dependencies of NETStandard.Library still get restored because MySqlConnector targets netstandard1.3, even though that has nothing to do with my project's target framework? (Or are you only describing what happens if it's installed into a project that itself targets netstandard1.3?)

If the former, I could certainly see dropping support for it to improve that scenario for almost all users. Deleting netstandard1.3 and netcoreapp1.1.2 would delete a bit of archaic code and extra integration test code paths.

bgrainger avatar Apr 21 '21 23:04 bgrainger

(Or are you only describing what happens if it's installed into a project that itself targets netstandard1.3?)

Right, the latter. You only get the transitive dependencies that are applicable to the tfms that your project targets.

ViktorHofer avatar Apr 21 '21 23:04 ViktorHofer

https://github.com/dotnet/announcements/issues/190:

For .NET 6 ... we're dropping anything older than: net461, netcoreapp3.1, netstandard2.0

bgrainger avatar Jun 18 '21 13:06 bgrainger

Split netstandard1.3 removal to https://github.com/mysql-net/MySqlConnector/issues/1031.

bgrainger avatar Sep 10 '21 12:09 bgrainger

Removing netcoreapp2.1: https://github.com/mysql-net/MySqlConnector/issues/1067.

bgrainger avatar Oct 24 '21 01:10 bgrainger

Per https://github.com/mysql-net/MySqlConnector/issues/1205, .NET Framework 4.5.2 and 4.6.1 reached end of support on 26 April 2022: https://devblogs.microsoft.com/dotnet/net-framework-4-5-2-4-6-4-6-1-will-reach-end-of-support-on-april-26-2022/

However:

Windows 10 Enterprise LTSC 2015 shipped with .NET Framework 4.6 built into the OS. This OS version is a long-term servicing channel (LTSC) release. We will continue to support .NET Framework 4.6 on Windows 10 Enterprise LTSC 2015 through end of support of the OS version (October 2025).

Adding support for .NET 7 could be a good time to retire the net45 TFM. The net461 TFM could be upgraded to net462, although I'm not sure if there are any concrete benefits gained by doing that.

bgrainger avatar Aug 19 '22 00:08 bgrainger

Split net45 removal to https://github.com/mysql-net/MySqlConnector/issues/1209.

bgrainger avatar Aug 19 '22 05:08 bgrainger

The net461 TFM could be upgraded to net462, although I'm not sure if there are any concrete benefits gained by doing that.

Doing so would allow the latest versions of System.Diagnostics.DiagnosticSource and Microsoft.Extensions.Logging.Abstractions to be used; this would be good to do for v2.3.

It could also allow System.IO.Pipelines to be added as a dependency, but that's likely still a future task.

bgrainger avatar Jan 01 '23 20:01 bgrainger