Add additional TFM to eliminate explicit dependency

[thompson-tomo]

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

[axunonb]

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]

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]

Targeting net60 looks more complex than expected:

• Migrating SmartFormat.ZString to net60 brings 56 warnings about nullability and type conflicts we cannot simply ignore. They all come from the fork of Cysharp.ZString v2.5.1
• BuildingCysharp.ZString v2.6.0 with netstandard2.0, netstandard2.1 and net60 works fine (of course), but the build targeting .NET 4.6.1 is 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.
• We could reference Cysharp.ZString v2.6.0 directly as a nuget package, and offer the NetStandard2.0 build as the replacement for the native.NET 4.6.1 build. This results in a breaking change for .Net Framework users.
• We could freeze the .NET 4.6.1 build down to Cysharp.ZString v2.5.1 that we currently use. For the other target frameworks we reference Cysharp.ZString v2.6.0 nuget package. Feasible, but increases complexity.

@karljj1 @thompson-tomo Appreciate your thoughts about the best way to go.

[thompson-tomo]

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]

Yes, taking netstandard2.0 assemblies for .NET 4.6.1 would be nice, and all tests succeed. So we could keep .NET 4.6.1 as a target fx and still reference Cysharp.ZString v2.6.0. Not sure, whether this should be considered a breaking change? I tend to "no". What do you think?

[thompson-tomo]

I also wouldn't consider it a breaking

[axunonb]

Resolved with #389