Hi,
Gremlin.Net currently behaves differently if, e.g., Next() is called on a traversal that has no (more) results for .NET 8 than for earlier .NET versions. It returns null for earlier .NET versions but throws an exception on .NET 8. (This is tracked in TINKERPOP-3072 <https://issues.apache.org/jira/browse/TINKERPOP-3072> .) A minimal example to better illustrate what I'm talking about: g.V().Has("Name", "doesnotexist").Next(); Result: On .NET 7 and earlier: null On .NET 8: System.InvalidOperationException: Enumeration already finished. So, there is already a breaking change if users upgrade their .NET version to .NET 8. However, throwing an exception in this case seems to be the expected behaviour in general for Gremlin as that's what other GLVs do. I at least checked this for Java and Python. Java throws a NoSuchElementException and Python a StopIteration error. That is why I think that the correct thing for Gremlin.Net is to also throw an exception here as we should have consistent behaviour across GLVs. In that case, we should of course throw the exception here irrespective of the .NET version used. If we want to consistently throw an exception in .NET, then the question is when we want to make this change: In the next patch releases on 3.6 / 3.7 or wait until 3.8.0? I don't have a strong preference here but tend slightly towards adding the breaking change on 3.6/3.7 because I think that it's confusing for users to get different behaviour only by updating to .NET 8. If we make this change in the next release, then we at least have a consistent behaviour across GLVs and also across .NET versions. In general, users are only affected by this if they are relying on behaviour that has only been present in the .NET GLV. Any opinions on this? If there are no objections in the next 72 hours, then I'll assume lazy consensus in favour of a) letting Gremlin.Net throw an exception here (to be consistent with other GLVs) and b) introducing this change with the next 3.6/3.7 releases.
