search

AdamWhiteHat / BigDecimal

An arbitrary-precision decimal (base 10) floating-point number class. Over 2.5 million downloads on NuGet!
MIT License
53 stars 15 forks source link

Do we still want to keep the .NET 5 as an option? #10

Closed Protiguous closed 1 year ago

Protiguous commented 2 years ago

I'm now seeing this warning on compile in my experimental branch.

warning NETSDK1138: The target framework 'net5.0' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

Microsoft's Download .NET 5.0 reads:

This release has reached end of life, meaning it is no longer supported. We recommend moving to a supported release, such as .NET 7.0. See our support policy for more details.

I don't see any problem with leaving it available, except for the possibility that a security flaw might be discovered in .NET 5. I will continue to work with .NET 5 until I hear otherwise.

AdamWhiteHat commented 2 years ago

Naw, there is no need to stay on .NET 5. Feel free to upgrade it and submit a PR, or if that's a bit of a hassle because of changes made in your fork/branch then lemme know and I can git 'er don

AdamWhiteHat commented 1 year ago

Scratch that. Yeah, lets keep it. I'm making all my math/numeric libraries have the same set of target frameworks, and this set includes .NET 5.

The reason I'm making all my libraries support the same set of target frameworks is because I have a 'generic arithmetic' library that performs arithmetic on the generic type T, which my GenericPolynomial and GenericMultivaritePolynomial libraries use, and the test projects for these generic polynomial libraries take a dependency on BigDecimal, BigRational, BigComplex, and so on and its hard to test against a target framework unless all these libraries also target it, so I'm standardizing the set of target frameworks across all of them.

In regards to security, I think it is unlikely that anything we are doing is going to result in a security problem; we are not deserializing arbitrary data, we are not writing to the filesystem or making system API calls, we are not elevating privileges and we are not using pointers or unsafe code or anything like that, so I think the risk is low.