Proposed .NET version compatibility

[goofballLogic]

We need to decide which versions of .NET we support going forward. I've stolen the matrix below from https://github.com/dotnet/standard/blob/master/docs/versions.md which aligns .NET versions with .NET Standard. I propose that given the nature of this library which should aim to support the lowest version of .NET standard across all the different platforms.

This implies that we would only actively support .NET Framework 4.6 or later. Very open to cries of protest and condemnation, but I think we should timebox this to 1 month for interested parties?

.NET Standard	1.0	1.1	1.2	1.3	1.4	1.5	1.6	2.0	2.1
.NET Core	1.0	1.0	1.0	1.0	1.0	1.0	1.0	2.0	3.0
.NET Framework	4.5	4.5	4.5.1	4.6	4.6.1	4.6.11	4.6.11	4.6.11	N/A2
Mono	4.6	4.6	4.6	4.6	4.6	4.6	4.6	5.4	6.4
Xamarin.iOS	10.0	10.0	10.0	10.0	10.0	10.0	10.0	10.14	12.16
Xamarin.Mac	3.0	3.0	3.0	3.0	3.0	3.0	3.0	3.8	5.16
Xamarin.Android	7.0	7.0	7.0	7.0	7.0	7.0	7.0	8.0	10.0
Unity	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	TBD
Universal Windows Platform	8.0	8.0	8.1	10.0	10.0	10.0.16299	10.0.16299	10.0.16299	TBD

[wattsm]

4.6 seems a fair sensible baseline. v1.0.6 (which is the version on NuGet) targets .Net Standard 1.3, and .Net framework 4.0 and 4.5 (with different profiles).

[wattsm]

I assume that v1.0.6 was either published to NuGet manually or there used to be a CI pipeline setup somewhere outside of GitHub. The build script does not appear to push to NuGet, nor do the GitHub actions thare are currently configured unless I'm missing something.

[asbjornu]

I propose that given the nature of this library which should aim to support the lowest version of .NET standard across all the different platforms.

What does that mean, practically? Personally I think we can yank it up to .NET Standard 2.0, since that still supports all platforms. That would be a breaking change requiring a major version bump, though.

The build script does not appear to push to NuGet, nor do the GitHub actions thare are currently configured unless I'm missing something.

I've started a new CI/CD pipeline in #58. I can describe within it how I picture the build process is going to look like.

[goofballLogic]

Given that this library aims to be the go-to library for JSON-LD in .Net, is it worth attempting to retain compatibility with .NET Standard 1.0 for the algorithms themselves? We could then support enhanced versions of the API which can optionally be installed to allow for integration with Json.NET and/or System.Text.Json (.NET Core 3+).

Something like this perhaps:

                    +--------------------------+
                    |                          |
JObject-based API   |  json-ld.newtonsoft.net  +----+
                    |                          |    |    +---------------+
                    +--------------------------+    |    |               |
                                                    +---->  json-ld.net  |  string-based API and implementation
                    +--------------------------+    |    |               |
                    |                          |    |    +---------------+
System.Text.Json    |  json-ld.system.net      +----+
-based API          |                          |
                    +--------------------------+

[asbjornu]

I think such a separation and refactoring of the code base makes a lot of sense, @goofballLogic. I'm a strong proponent of having a core domain model completely dependency-free and only consisting of idiomatic C# code and having ancillary projects building and extending the core with references and dependencies to the outside world as per hexagonal architecture, onion architecture, clean architecture, etc.

[goofballLogic]

The other thing that might be worth considering is better support for DI. I know that the static classes provided are probably a good design decision for implementing the (basically stateless) JSON-LD algorithms, but it might be nice to provide an interface-based implementation to help when people would like to inject the library into their code in such a way that it can be mocked for unit testing, shimmed and decorated etc.

[asbjornu]

100% agreed, @goofballLogic. Static, state- and side-effect-free methods make sense in a functional language, but in C# where DI containers are prevalent, immutability is difficult to guarantee and (shared) state is almost impossible to get rid of, I think an interface-based approach both sits better with the language and makes for a much more testable, readable, intuitive and robust codebase.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[goofballLogic]

Hmm. why did stale bot mark this as stale @asbjornu ? It is on a milestone.

[asbjornu]

I guess because #80 was only merged yesterday, @goofballLogic.