Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet * https://github.com/JanusGraph/janusgraph-python Committers and maintainers should have access to it.

Not sure which SO post you mean, but you can simply verify that it's working when you try this: and check that id is a valid RelationIdentifier. Great, I implemented a JanusGraphClientBuilder for the

Congratulations Florian and Chris! Thanks for all your excellent work on the project.

Thanks a lot Florian for pointing out the JSON structure difference in case of Circle. I just wrapped around the JSON inside a geometry key, and did the normal workflow I was doing before, and I'm

The serialization of Geoshape.Point needs to look exactly like what you got back from the server: {'@type': 'janusgraph:Geoshape', '@value': {'coordinates': [23.700001, 38.099998]}} My advise for

Okay, adding a few things here. I was doing quick debug and added following logs to my PointSerializer & CircleSerializer class' dictify method which is used during Serialization. serializedJSON =

Hi Florian. Thanks for all those tips. I made huge proceedings today in concern with Geoshapes. Thanks for pointing out that Geoshape and Geopredicate are 2 separate things. Somehow it was oversight

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome 2 new committers on the project! Florian Hockmann has been a solid contributor. In the JanusGraph 0.3.0 release,

There is a difference between Geoshapes and Geo predicates. You are right that Geo predicates are similar to Text predicates and don't need their own serializer as the normal serializer for P (that's

Hi Florian, Thanks for response. Well my understanding was that the implementation was going to be similar for all Geoshapes. I guess my understanding was wrong here. Thanks for pointing that out. If

First of all, great to hear that someone is working on a Python driver for JanusGraph! At a first glance I'd say that the serialization of Geoshape.circle() looks wrong. You serialize them as if they

+1 on Jason's idea. This helps people who are bit busy with other assignments to have easy way to track the existing PRs needed for approval, and in turn reduces chances of PR reviews getting missed

Hi all, I'm currently building JanusGraph libraries for Python so that we can extend functionalities of JanusGraph indexed lookup and Schema management using non JVM based languages. I was planning a

Perhaps a weekly update on the PR queue posted on the dev mailing list would be a good idea. Something like: # 0.2.2 queue PR a - needs one more approval PR b - waiting on revisions PR c - unreviewed

Finding the right balance between more review/more approvals and being more efficient is what we aim for. I have been in situations in my PRs where another pair of eyes caught some error I made. I

I agree that maintaining 3 development branches will be tough for us. Ideally we should avoid it at this stage of the project. I am for a last release of 0.2.2 as Jason plans it. (The three PRs don't

I am not a committer but here are my thoughts: 1. I think it is enough to maintain 2 active branches right now. Latest release + future release (master). There is plainly no enough committers to

I have a couple discussion topics to bring up based on our recent history of getting releases out. 1. Based on what we have written in the docs (Chapter 44. Pull Requests), we have a

I created a milestone for the 0.2.2 shortly before 0.2.1 was released. The 0.2 branch is open and the versions are updated to 0.2.2-SNAPSHOT. These are the open PRs that require review/approvals. A

+1 good job on the hard work for release!