Gremlin.net for .net 8
Hi all, when can we expect a Gremlin.net version targeting .net 8? Gremlin.net’s latest version v3.7.3 only supports .net 6 which is out of support.
Solution:Jump to solution
Hi @lijinv, could you expand on any issues you may be seeing when attempting to use Gremlin.net with .net 8? .net 8 should be fully supported as of v3.7.2, and we currently run all of our Gremlin.net testing in .net 8. https://issues.apache.org/jira/browse/TINKERPOP-3030.
If you have found any incompatibilities with v3.7.3 in .net 8, that should likely be considered a bug....
5 Replies
Solution
Hi @lijinv, could you expand on any issues you may be seeing when attempting to use Gremlin.net with .net 8? .net 8 should be fully supported as of v3.7.2, and we currently run all of our Gremlin.net testing in .net 8. https://issues.apache.org/jira/browse/TINKERPOP-3030.
If you have found any incompatibilities with v3.7.3 in .net 8, that should likely be considered a bug.
Hi Cole, I was just going off of nuget documentation which only calls out .NET 6. Will upgrade and report any issues if found. Thanks for the response!
I see. @Florian Hockmann do you know if it's intentional that the nuget docs only list
.NET 6 and .NET Standard 2?Gremlin.Net 3.7.3
Gremlin.Net for Apache TinkerPop™ is a language variant and driver for .NET.
Apache TinkerPop™ is a graph computing framework for both graph databases (OLTP) and graph analytic systems (OLAP). Gremlin is the graph traversal language of TinkerPop. It can be described as a functional, data-flow language that enables users to succinctly express co...
Yes, .NET targeting works like this:
A library should target the lowest framework versions it supports. These are .NET 6 and .NET Standard 2.0 in our case.
All higher framework versions and all framework versions that implement that .NET Standard version are also supported automatically by this. .NET 7 and .NET 8 include everything that's inside .NET 6 and extend it with additional functionality & APIs. That's why they can consume libraries targeting lower .NET versions. There's no disadvantage in not having an explicit .NET 7 or .NET 8 target. Libraries only need to target those versions additionally if they want to use some of their additionaly APIs. In that case, they could build one version for .NET 6 which doesn't use the additional APIs and one version for .NET 7 / .NET 8 which uses the new APIs.
The same applies to .NET Standard 2.0 / .NET Standard 2.1. And .NET Standard 2.0 is implemented by a lot of other .NET frameworks like .NET 5, Mono and Xamarin. That's why a package targeting .NET Standard 2.0 can also be used on those frameworks.
The nuget docs shows all framework versions where our package can be used in light blue (compatible target framework(s)), but only the versions that we explicitly target in dark blue, but that shouldn't be important for users. The light blue versions are the interesting versions for users
That makes sense but just the other day I ran into another nuget package (System.Text.Json) which throws a Build warning when upgraded to v9.0.1 that it hadn't been tested with .NET 6 and was meant for .NET 8 even though the nuget documentation does mark it as compatible with .NET 6. Maybe it's a one off but that's why I thought to check.