Proposed .NET version compatibility about json-ld.net

[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.

[asbjornu]

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

[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          |                          |
                    +--------------------------+

[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.