(WIP) Generic DataFrame Math #6664
Conversation
ghost
assigned 
|
|
||
| using System.Runtime.Versioning; | ||
|
|
||
| [assembly: RequiresPreviewFeatures] |
There was a problem hiding this comment.
Is this because you're targeting .NET 6?
The API surface of the generic math interfaces changed between 6 and 7 (such as moving all interfaces into namespace System.Numerics) and it would likely be better to keep this targeting 7/8
There was a problem hiding this comment.
Yeah - figured targeting the LTS made sense. @ericstj Thoughts?
There was a problem hiding this comment.
I think if we're making this change, we'd want to target .NET 8 (LTS) and plan to ship it around or after November
There was a problem hiding this comment.
The approach we have recently been taking with NuGet packages here and in dotnet/runtime is to retain support for in-support frameworks. This is better than the previous approach which was never drop support for anything due to compatibility. .NET 6 remains in support until November of 2024 so our current plan would be to keep supporting it until then.
ML.NET's servicing story so far has been "update to latest" - we only maintain one active release branch. I could imagine a change where we start dropping in-support frameworks from our nuget package, but in conjunction with such a change we'd need to maintain more servicing branches, and as a result servicing changes would become more expensive since we'd need to port them between many codebases.
There was a problem hiding this comment.
I think this would be a special consideration for .NET 6 vs .NET 8 and won't be "normal" as we don't often get features as big as generic math.
So we'd need to maintain a servicing branch for 6, but then wouldn't need to the same for 8 vs 10 without some other feature that is as meaningfully impactful
There was a problem hiding this comment.
In this case what's the benefit from not supporting 6.0? Is it just removing that attribute or is there more to it?
There was a problem hiding this comment.
There were concrete breaking changes to the API surface of the generic math feature between .NET 6 and .NET 7
We'd be maintaining two copies of the generic math code, one in preview and one "feature complete" as well as dealing with any subtle bugs or missing support in the broader product from it being an early preview.
There was a problem hiding this comment.
This PR also removes support for netstandard2.0 and full .Net frameworks (like 4.8, which is as far as I undertans also LTS). The company I worked before, used DataFrame on .Net 4.6.2 and they didn't have plan to migrate to .net core in the nearest future.
Could you please make at least one more release of Microsoft.Data.Analysis nuget targeting netstandart2.0 for such clients before moving to ,Net 8 (6) only?
There was a problem hiding this comment.
@asmirnov82 we're still figuring out the timelines for this change but it will be after the next release.
Thanks for working with us!
JakeRadMSFT
force-pushed
the
u/jakerad/generic-math
branch
from
0abcc03
to
c42c1e2
Compare
Take jakerad/generic_math changes without conflicts
# Conflicts: # src/Microsoft.Data.Analysis/DataFrame.IO.cs # test/Microsoft.Data.Analysis.Tests/Microsoft.Data.Analysis.Tests.csproj
# Conflicts: # src/Microsoft.Data.Analysis/DataFrameColumnCollection.cs # test/Microsoft.Data.Analysis.Tests/DataFrameTests.cs
# Conflicts: # src/Microsoft.Data.Analysis/DataFrameColumnCollection.cs
# Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumn.cs
# Conflicts: # src/Microsoft.Data.Analysis/BooleanDataFrameColumn.cs # src/Microsoft.Data.Analysis/ByteDataFrameColumn.cs # src/Microsoft.Data.Analysis/CharDataFrameColumn.cs # src/Microsoft.Data.Analysis/DateTimeDataFrameColumn.cs # src/Microsoft.Data.Analysis/DecimalDataFrameColumn.cs # src/Microsoft.Data.Analysis/DoubleDataFrameColumn.cs # src/Microsoft.Data.Analysis/Int16DataFrameColumn.cs # src/Microsoft.Data.Analysis/Int32DataFrameColumn.cs # src/Microsoft.Data.Analysis/Int64DataFrameColumn.cs # src/Microsoft.Data.Analysis/SByteDataFrameColumn.cs # src/Microsoft.Data.Analysis/SingleDataFrameColumn.cs # src/Microsoft.Data.Analysis/UInt16DataFrameColumn.cs # src/Microsoft.Data.Analysis/UInt32DataFrameColumn.cs # src/Microsoft.Data.Analysis/UInt64DataFrameColumn.cs # test/Microsoft.Data.Analysis.Tests/DataFrame.IOTests.cs
# Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumn.BinaryOperations.tt
# Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.cs # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.tt
# Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.cs # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.tt
JakeRadMSFT
force-pushed
the
u/jakerad/generic-math
branch
from
287293c
to
9836b30
Compare
Integrate latest dataframe changes from asmirnov/machinelearning into local branch
# Conflicts: # src/Microsoft.Data.Analysis/DataFrameColumn.BinaryOperations.tt # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumn.BinaryOperations.cs # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumn.BinaryOperations.tt
# Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnComputations.cs # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnComputations.tt
…eral value buffers) # Conflicts: # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.cs # src/Microsoft.Data.Analysis/PrimitiveDataFrameColumnArithmetic.tt
Integrated 6733 Jakerad generic math
No description provided.