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.