|
[VOTE] JanusGraph 0.4.0 release
Florian Hockmann <f...@...>
Hello, We are happy to announce that JanusGraph 0.4.0 is ready for release. The release artifacts can be found at this location: https://github.com/JanusGraph/janusgraph/releases/tag/v0.4.0 A binary distribution is provided for user convenience: https://github.com/JanusGraph/janusgraph/releases/download/v0.4.0/janusgraph-0.4.0-hadoop2.zip The GPG key used to sign the release artifacts is available at: https://github.com/JanusGraph/janusgraph/releases/download/v0.4.0/KEYS The docs can be found here: https://github.com/JanusGraph/janusgraph/releases/download/v0.4.0/janusgraph-0.4.0-hadoop2-doc.zip (See also documentation preview site) The release tag in Git can be found here: https://github.com/JanusGraph/janusgraph/tree/v0.4.0 The release notes are available here: https://github.com/JanusGraph/janusgraph/blob/v0.4.0/docs/changelog.adoc This [VOTE] will open for the next 3 days --- closing Friday, July 5, 2019 at 10:00 PM CEST (UTC+2). All are welcome to review and vote on the release, but only votes from TSC members are binding. My vote is +1. Thank you, Florian Hockmann |
|
|
|
Re: [DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Oleksandr Porunov <alexand...@...>
I also think that we need some policy but it is hard to say right now where should this "enhancement" go. Some improvements cannot go to older branches and some can. For example, it could be a storage version related enhancement in such case the enhancement must go to the branches where it would work (i.e. to the oldest branch where this storage version is enabled). Other improvements could be based on some work which is done in some branch. For example, we could refactor code in the latest branch and not in the old branches and the improvement is easily applied to the refactored code but is hard to be applied to old code in old branches. In such case I would say that the contributor should decide where it should be applied. I.e. in some cases the improvement can be applied to old branches but with a lot of additional work which the contributor don't won't to do. So it is hard for me to suggest a single policy which will work for everyone. I would say, it depends on the concrete case. P.S. I am using "enhancement" and "improvement" as synonims. By "enhancement" I mean "improvement" and not "new funcionality". On Tuesday, July 2, 2019 at 4:40:42 PM UTC+3, Florian Hockmann wrote:
|
|
|
|
[DISCUSS] Accept money contributions
Oleksandr Porunov <alexand...@...>
Hello, I didn't research much, but I think we could try to enable some platform which will work to collect money contributions which we can spent on some expenses. I didn't research much how it works but I think we could use the contributed money for something like: - Buy commercial Travis plan to be able to run TinkerPop tests clearly https://travis-ci.com/plans - Hiring a full-time developer / developers to the project - Tickets to conferences to present JanusGraph It is just a simple ideas. I didn't research deep but the platforms we could look at are: - possibly some other platforms What the community think about this step? Do you think it could be useful? Best regards, Oleksandr Porunov |
|
|
|
Re: [DISCUSS] JanusGraph 0.5.0 release
Jason Plurad <plu...@...>
+1 If there are folks in the community that want continued support for old/non-supported versions of backend dependencies, we would need those same folks to step up to help managing those maintenance branches. If you fall into that category, please speak up. On Tuesday, July 2, 2019 at 4:46:13 AM UTC-4, Jan Jansen wrote:
|
|
|
|
Re: [DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Florian Hockmann <f...@...>
I'm fine with adding labels for features and breaking changes, but where I'm not sure about is this part:
Who decides here which branch to target? The contributor? Any reviewer? I think we should have a policy that specifies which kind of contribution should target which branch and it should ideally be easy to understand. Am Dienstag, 2. Juli 2019 15:38:29 UTC+2 schrieb Jason Plurad:
|
|
|
|
Re: [DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Jason Plurad <plu...@...>
Ah, fair enough, enhancement makes sense when explained more fully by example. On Monday, July 1, 2019 at 9:19:00 AM UTC-4, Oleksandr Porunov wrote:
|
|
|
|
Re: [DISCUSS] JanusGraph 0.5.0 release
Jan Jansen <faro...@...>
I would also add dropping of Cassandra 2 support (including Thrift). These feature set sounds good for me to be integrate into JanusGraph 0.5. The update of TinkerPop 3.4.2 could be integrate also into 0.4.x. Greetings, Jan |
|
|
|
[DISCUSS] JanusGraph 0.5.0 release
Oleksandr Porunov <alexand...@...>
Hi everyone, 0.2.3 and 0.3.2 are released and 0.4.0 is going to be released soon. I would like to add a new feature "Add support for ElasticSearch 7". The feature makes a small breaking changes, that is why it should be targeted to a new "feature branch". We discussed earlier that the community cannot support more than 2 branches right now. I see a small drawback in dropping support for "0.3" branch because all users who are running ES < 5 or Solr < 7 or Cassandra < 2.1 will not be supported anymore. But on the other side, we cannot support deprecated backends for too long. That is why, I would suggest creating "0.4" branch, making "master" branch as "0.5.0-SNAPSHOT" and support "0.3" branch till 0.3.3 release. After that we will support only "0.4" and "master" branches. In "0.5" release I would like to propose include: - Adding support for ES 7 (#1648) - Dropping mapping types for either ES 7 or ES 8 (need to discuss). We are required to drop support for mapping types in ES 8 but ES 7 mapping types are optional (can be dropped or saved). - Drop support for ES < 6 because ES 5.x is EOL - Do not retrieve unnecessary fields during index search (#1647 and #1652) - Update TinkerPop to 3.4.2 - Add support for raw lucene date range queries (#1615) - Extract JanusGraph Gremlin driver requirements (#1521) What the community members think about it? Are you OK with making "0.3.3" the last release in "0.3" branch and moving current master to "0.4" branch after the "0.4.0" release? I am proposing to make releases faster with smaller changes instead of waiting for a lot of changes to arrive. I don't see anything bad if we release one release every 1 or 2 months with several small changes. Best regards, Oleksandr Porunov |
|
|
|
Re: [DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Oleksandr Porunov <alexand...@...>
If an issue suggests a performance improvement, can we label it as a "bugfix"? On Monday, July 1, 2019 at 3:59:52 PM UTC+3, Jason Plurad wrote:
|
|
|
|
Re: [DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Jason Plurad <plu...@...>
I think "enhancement" can be easily confused with "feature". I'd suggest to stick with "bugfix" for items that would go into any branch. On Monday, July 1, 2019 at 7:34:59 AM UTC-4, Oleksandr Porunov wrote:
|
|
|
|
[DISCUSS] PR targeting for enhancement, feature, bugfix and breaking changes
Oleksandr Porunov <alexand...@...>
Hello, Currently both new features and enhancements are labeled as "enhancement". I am proposing to introduce new labels: - "feature" - a new functionality - "breaking changes" - breaking changes After that I am proposing to use the next PR targeting scheme: - "breaking changes" and "feature" can go only to master branch - "enhancement" and "bugfix" can go to any branch I don't think that we need a special voting for this that is why I will wait for 1 week for other comments from contributors. If everyone is OK with it then we can stick to a new PR targeting scheme Best regards, Oleksandr |
|
|
|
Re: JanusGraph Online Meetup #2 Call for Speakers
Ted Wilmes <twi...@...>
Hello, bumping this thread again to see if any folks have something JanusGraph related they'd enjoy presenting. Last time we had great talks on the state of JanusGraph, a new approach to JanusGraph schema management, data loading tips & tricks, the ODPi Foundation, data modeling. As more and more folks are using JanusGraph in production and trying it out, any real world experiences (both good and bad!) would be well received by the community. Let me know if you have interest and I'm happy to chat further. Thanks! Ted On Mon, Jun 17, 2019 at 11:35 AM Ted Wilmes <twi...@...> wrote:
|
|
|
|
JanusGraph - OLAP - YARN (Hadoop 3.x)
polaco...@...
Hello, Has anyone tried to run OLAP queries on HDP 3.1, using HBase 2x with YARN? I managed to succesfully run JanusGraph on HBase 2.0.2, but I am not able to run queries using SparkGraphComputer, with YARN. I am stuck at this error: I was able to succesfully run OLAP queries on older HDP versions for example 2.6.3, these types of errors did not occur. If I understand it correctly TinkerPop now does not support Hadoop 3.x, meaning currently it is not possible to execute OLAP queries using YARN? Thanks, Juraj |
|
|
|
Re: [DISCUSS] JanusGraph 0.4.0 release
Florian Hockmann <f...@...>
Hey Chris, there are currently only two open PRs left for the 0.4.0 release and I think that we should really release 0.4.0 as soon as possible, considering how long it has been since the last release from master. I hope that we can merge these 2 PRs soon and then release 0.4.0 at the beginning of next week. If someone provides a PR that we can review and merge in the next few days, then we can probably include it for 0.4.0. But since Oleksandr already gave that update a try and found out that it's non-trivial, I think we can better include it for 0.4.1. There is also no reason in general not to release 0.4.1 relatively soon after 0.4.0. TinkerPop recently moved to a release schedule every 2 months and the experience looks good so far. One advantage of more frequent releases is that it doesn't really matter so much any more when a certain issue is fixed as there is no big difference in getting a fix included in the next release or in another release just 2 months later. Regards, Florian Am Dienstag, 25. Juni 2019 21:07:13 UTC+2 schrieb Chris Hupman:
|
|
|
|
Re: [DISCUSS] JanusGraph 0.4.0 release
Chris Hupman <chris...@...>
Hey Florian, I was looking at the changelog for Tinkerpop 3.4.2 and saw a couple of improvements that look really nice.
Do you think it would be possible to update to TinkerPop 3.4.2 in JanusGraph 0.4.1? The ability to override the script timeout value without restarting the server would be a very nice addition. Regards, Chris On Friday, June 7, 2019 at 7:26:49 AM UTC-7, Florian Hockmann wrote:
|
|
|
|
Re: Can I invite a JanusGraph developer in this group to work on a project?
Scott Heath <scott...@...>
Vladamir Expero, the company I work with specializes in many types of JanusGraph work. Here is a link if that assists Regards Scott Heath | Expero Inc | www.experoinc.com | P: +1 512.368.6080 | E: scott...@... | On Mon, Jun 24, 2019 at 9:22 AM Vladimir Katansky <pointho...@...> wrote:
|
|
|
|
Can I invite a JanusGraph developer in this group to work on a project?
Vladimir Katansky <pointho...@...>
Hello, It might not be appropriate but I'm looking for help in a way of hiring an expert who could help create GraphDB structure, Gremlin Scripts to fetch data and establish a connection so we can visualise the data and its connections. If it's appropriate please suggest someone who could help or just remove this topic. With Kind Regards, Vladimir |
|
|
|
[RESULT][VOTE] JanusGraph 0.3.2 release
Oleksandr Porunov <alexand...@...>
This vote is now closed with a total of 4 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Florian Hockmann, Jason Plurad, Jerry He) 0 (0) -1 (0) NON-BINDING VOTES: +1 (1 -- Oleksandr Porunov) 0 (0) -1 (0) Thank you very much, Oleksandr Porunov |
|
|
|
Re: [VOTE] JanusGraph 0.3.2 release
Jerry He <jerr...@...>
+1 Thanks for the work, Oleksandr. Jerry On Thu, Jun 20, 2019 at 9:04 AM Oleksandr Porunov <alexand...@...> wrote:
|
|
|
|
Re: [VOTE] JanusGraph 0.3.2 release
Oleksandr Porunov <alexand...@...>
We have 3 +1 votes, however we have only 2 +1 votes from TSC members, which falls short of the 3 required for the release. Oleksandr Porunov Florian Hockmann * Jason Plurad * * denotes TSC member I'm going to extend the voting process until we get one more vote from a TSC member. If there are any concerns with this approach, please reply on this thread. Thank you. On Monday, June 17, 2019 at 6:04:07 PM UTC+3, Oleksandr Porunov wrote:
|
|
|