|
Jason Plurad <plu...@...>
Florian Hockmann is ready to contribute a .NET driver for JanusGraph. The pull request is currently found in the main janusgraph repo. The driver extends the TinkerPop .NET driver with additional capability for JanusGraph types and predicates. In a previous dev list discussion thread, he and I discussed making a separate repository for this body of work. I propose the name janusgraph-dotnet for the repository. Let's give it 72 hours for lazy consensus. I'm +1 for this. Looking forward to getting better driver support as part of the broader project.
|
|
|
Debasish Kanhar <d.k...@...>
+1 from my side :-) Really like the idea here :-)
On Saturday, 28 July 2018 20:36:10 UTC+5:30, Jason Plurad wrote: Florian Hockmann is ready to contribute a .NET driver for JanusGraph. The pull request is currently found in the main janusgraph repo. The driver extends the TinkerPop .NET driver with additional capability for JanusGraph types and predicates. In a previous dev list discussion thread, he and I discussed making a separate repository for this body of work. I propose the name janusgraph-dotnet for the repository. Let's give it 72 hours for lazy consensus. I'm +1 for this. Looking forward to getting better driver support as part of the broader project.
|
|
|
Misha Brukman <mbru...@...>
+1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
|
|
|
Florian Hockmann <f...@...>
Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
https://github.com/FlorianHockmann/janusgraph-dotnet
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman:
+1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Jason Plurad <plu...@...>
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.
On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Florian Hockmann <f...@...>
Looks like I don't have access to it. At least I can't see its settings or anything. Do I need to be member of the JanusGraph org for that? Am Mittwoch, 15. August 2018 00:45:27 UTC+2 schrieb Jason Plurad:
Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Jason Plurad <plu...@...>
You're right, we'll get you updated on that list.
On Wednesday, August 15, 2018 at 7:11:45 AM UTC-4, Florian Hockmann wrote: Looks like I don't have access to it. At least I can't see its settings or anything. Do I need to be member of the JanusGraph org for that? Am Mittwoch, 15. August 2018 00:45:27 UTC+2 schrieb Jason Plurad: Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Florian Hockmann <f...@...>
Thanks, I'm now member of the group and apparently have write access to all JanusGraph repos, except for the two new ones: janusgraph-dotnet and janusgraph-python. I get permission denied when I try to push something there and I also can't set an assignee in the New Issue dialogue which should be possible with write access (this works now for the other repos). Could you please check the permissions again for the two repos? Am Mittwoch, 15. August 2018 15:40:12 UTC+2 schrieb Jason Plurad:
You're right, we'll get you updated on that list. On Wednesday, August 15, 2018 at 7:11:45 AM UTC-4, Florian Hockmann wrote: Looks like I don't have access to it. At least I can't see its settings or anything. Do I need to be member of the JanusGraph org for that? Am Mittwoch, 15. August 2018 00:45:27 UTC+2 schrieb Jason Plurad: Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Jason Plurad <plu...@...>
Doh, yet another GitHub setting update was required. Should be correct now.
On Wednesday, August 15, 2018 at 2:18:30 PM UTC-4, Florian Hockmann wrote: Thanks, I'm now member of the group and apparently have write access to all JanusGraph repos, except for the two new ones: janusgraph-dotnet and janusgraph-python. I get permission denied when I try to push something there and I also can't set an assignee in the New Issue dialogue which should be possible with write access (this works now for the other repos). Could you please check the permissions again for the two repos? Am Mittwoch, 15. August 2018 15:40:12 UTC+2 schrieb Jason Plurad: You're right, we'll get you updated on that list. On Wednesday, August 15, 2018 at 7:11:45 AM UTC-4, Florian Hockmann wrote: Looks like I don't have access to it. At least I can't see its settings or anything. Do I need to be member of the JanusGraph org for that? Am Mittwoch, 15. August 2018 00:45:27 UTC+2 schrieb Jason Plurad: Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
Misha Brukman <mbru...@...>
I'll populate the new JanusGraph repos with boilerplate license + DCO + Authors/contributors files, and then please feel free to follow the PR approach to bring in the code (and update copyright, etc.).
Thanks!
On Thu, Aug 16, 2018 at 11:11 AM, Jason Plurad <plu...@...> wrote: Doh, yet another GitHub setting update was required. Should be correct now. On Wednesday, August 15, 2018 at 2:18:30 PM UTC-4, Florian Hockmann wrote: Thanks, I'm now member of the group and apparently have write access to all JanusGraph repos, except for the two new ones: janusgraph-dotnet and janusgraph-python. I get permission denied when I try to push something there and I also can't set an assignee in the New Issue dialogue which should be possible with write access (this works now for the other repos). Could you please check the permissions again for the two repos? Am Mittwoch, 15. August 2018 15:40:12 UTC+2 schrieb Jason Plurad: You're right, we'll get you updated on that list. On Wednesday, August 15, 2018 at 7:11:45 AM UTC-4, Florian Hockmann wrote: Looks like I don't have access to it. At least I can't see its settings or anything. Do I need to be member of the JanusGraph org for that? Am Mittwoch, 15. August 2018 00:45:27 UTC+2 schrieb Jason Plurad: Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
|
|
|
Misha Brukman <mbru...@...>
toggle quoted message
Show quoted text
On Thu, Aug 16, 2018 at 11:48 AM, Misha Brukman <mbru...@...> wrote: I'll populate the new JanusGraph repos with boilerplate license + DCO + Authors/contributors files, and then please feel free to follow the PR approach to bring in the code (and update copyright, etc.).
Thanks!
|
|
|
Florian Hockmann <f...@...>
|
|
|
Debasish Kanhar <d.k...@...>
@Jason:
I created a initial PR#2 to merge my codebase into official JanusGraph-Python repo you created. While the PR was successful, I wasn't able to add any reviewers, you or Florian or Misha. I'll need your inputs regarding copyright statements, liscence texts and other legal/similar formalities as well as other comments.
Also, had a query regarding status of merging fix #1060 into 0.2 stream of branched for JanusGraph, and if needed, I can work on it as that is currently only merged into master and 0.3. The discussion here will need your comments too :-)
Thanks.
On Wednesday, 15 August 2018 04:15:27 UTC+5:30, Jason Plurad wrote: Apologies for the delay, but I've created * https://github.com/JanusGraph/janusgraph-dotnet* https://github.com/JanusGraph/janusgraph-pythonCommitters and maintainers should have access to it. On Sunday, August 5, 2018 at 9:25:48 AM UTC-4, Florian Hockmann wrote: Looks like we have reached consensus here. I have already created a stand-alone version of the library in its own repo:
I can create a PR to transfer it to JanusGraph as soon as we have a repo ready to target the PR against.
Am Dienstag, 31. Juli 2018 20:47:11 UTC+2 schrieb Misha Brukman: +1
Makes sense that client libraries should be in a separate repo than the server: - enables a separate release cadence
- allows for a different set of maintainers, even in the same org
- each client library will be written in a different language
Having said that, this means that we'll have to keep track of version compatibilities between client library versions + server versions. Hopefully, they will be mostly backwards-compatible until a major version change.
|
|
|
