{{ message }}
Repository navigation
Add additional TFM to eliminate explicit dependency #380
Description
Is your feature request related to a problem? Please describe.
I want to minimise dependencies in my project by utilising framework dependencies wherever possible
Describe the solution you'd like
I want the package to have an additional TFM (net 6) added so that the explicit dependency on System.Text.Json can be removed.
Describe alternatives you've considered
Accept the additional dependency
Additional context
n/a
Metadata
Metadata
Assignees
Labels
No labels
Activity
axunonb commentedon Apr 14, 2024
Agree, NET60 is LTS and should become a target framework. Any reason not mentioning NET80 which is also LTS? Or newer NET80 instead of NET60?
thompson-tomo commentedon Apr 14, 2024
My preference is to target older frameworks ie net 6 so that more projects can benefit & only add the latest TFM where there is a benefit ie new language features or additional libraries bundled into the framework.
axunonb commentedon Apr 29, 2024
Targeting
net60looks more complex than expected:SmartFormat.ZStringtonet60brings 56 warnings about nullability and type conflicts we cannot simply ignore. They all come from the fork ofCysharp.ZStringv2.5.1Cysharp.ZStringv2.6.0 withnetstandard2.0,netstandard2.1andnet60works fine (of course), but the build targeting.NET 4.6.1is breaking. They implemented nice improvements, but the methods don't exist for.NET 4.6.1, This was somehow to be expected, because they dropped .Net Framework support since quite a while.Cysharp.ZStringv2.6.0 directly as a nuget package, and offer theNetStandard2.0build as the replacement for the native.NET 4.6.1build. This results in a breaking change for .Net Framework users..NET 4.6.1build down toCysharp.ZStringv2.5.1 that we currently use. For the other target frameworks we referenceCysharp.ZStringv2.6.0 nuget package. Feasible, but increases complexity.@karljj1 @thompson-tomo Appreciate your thoughts about the best way to go.
thompson-tomo commentedon May 6, 2024
My thoughts would be to switch to 2.6.0 nuget rather than the fork to improve maintaince going forward. If I am not mistaken you should be able to consume a net standard 2.0 library in net framework 4.6.1 hence I think we might be ok. If it doesn't then we should evaluate bumping the major so net framework can be dropped &/or conditional compilation. Could we conditional just the nuget hence maintenance should be more manageable.
axunonb commentedon May 8, 2024
Yes, taking
netstandard2.0assemblies for.NET 4.6.1would be nice, and all tests succeed. So we could keep.NET 4.6.1as a target fx and still referenceCysharp.ZStringv2.6.0.Not sure, whether this should be considered a breaking change? I tend to "no". What do you think?
thompson-tomo commentedon May 8, 2024
I also wouldn't consider it a breaking
#380 Add net60 as additional target framework (#381)
Target Framework Updates (#389)
axunonb commentedon May 15, 2024
Resolved with #389