Date   

Re: [DISCUSS] JanusGraph 0.5.0 release

Chris Hupman <chris...@...>
 

+1

I'd really like to see all of our current known github vulnerabilities get addressed in 0.5.0 as well.

Also we should add a graph of the gods with schema constraints to improve testing and user adoption of the feature.

Chris


Re: [VOTE] JanusGraph 0.4.0 release

Abhay Pandit <abha...@...>
 

VOTE: +1

On Fri, 5 Jul 2019 at 01:48, Ted Wilmes <twi...@...> wrote:
Release looks good. I verified signatures, skimmed through the docs, extracted the zip, tried out some of the new features listed in the change log (lots of good stuff in here!) and then ran a set of Gatling tests.

VOTE: +1

Thanks,
Ted

On Tuesday, July 2, 2019 at 3:08:38 PM UTC-5, Oleksandr Porunov wrote:
Downloaded release artifacts. 
- Check the key exists in KEYS file: Done
- Verify janusgraph-0.4.0-hadoop2.zip and janusgraph-0.4.0-hadoop2-doc.zip with asc keys: Done
- Extract janusgraph-0.4.0.zip, build jars from it, include into personal project, check that all integration tests pass (ScyllaDB 3.0.3, ElasticSearch 6.6.0): Done
- Check version related documentation changes: Done

My VOTE is +1

On Tuesday, July 2, 2019 at 10:34:22 PM UTC+3, Florian Hockmann wrote:
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

--
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 janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/fa7bb27b-b4e6-484a-8994-f62d133c3d9d%40googlegroups.com.


Re: [VOTE] JanusGraph 0.4.0 release

Ted Wilmes <twi...@...>
 

Release looks good. I verified signatures, skimmed through the docs, extracted the zip, tried out some of the new features listed in the change log (lots of good stuff in here!) and then ran a set of Gatling tests.

VOTE: +1

Thanks,
Ted


On Tuesday, July 2, 2019 at 3:08:38 PM UTC-5, Oleksandr Porunov wrote:
Downloaded release artifacts. 
- Check the key exists in KEYS file: Done
- Verify janusgraph-0.4.0-hadoop2.zip and janusgraph-0.4.0-hadoop2-doc.zip with asc keys: Done
- Extract janusgraph-0.4.0.zip, build jars from it, include into personal project, check that all integration tests pass (ScyllaDB 3.0.3, ElasticSearch 6.6.0): Done
- Check version related documentation changes: Done

My VOTE is +1

On Tuesday, July 2, 2019 at 10:34:22 PM UTC+3, Florian Hockmann wrote:
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: [VOTE] JanusGraph 0.4.0 release

Oleksandr Porunov <alexand...@...>
 

Downloaded release artifacts. 
- Check the key exists in KEYS file: Done
- Verify janusgraph-0.4.0-hadoop2.zip and janusgraph-0.4.0-hadoop2-doc.zip with asc keys: Done
- Extract janusgraph-0.4.0.zip, build jars from it, include into personal project, check that all integration tests pass (ScyllaDB 3.0.3, ElasticSearch 6.6.0): Done
- Check version related documentation changes: Done

My VOTE is +1


On Tuesday, July 2, 2019 at 10:34:22 PM UTC+3, Florian Hockmann wrote:
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


[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:
I'm fine with adding labels for features and breaking changes, but where I'm not sure about is this part:

"enhancement" and "bugfix" can go to any branch

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:
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:
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:
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:
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


[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:
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


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:

"enhancement" and "bugfix" can go to any branch

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:
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:
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:
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:
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: [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:
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:
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:
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: [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:
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:
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: [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:
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


[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:
Hello,
We're going to be hosting another JanusGraph online meetup on Wednesday July 24. There was a great turnout for the last one with lots of interactive Q&A from the audience. If you're interested in doing a 20 minute presentation on a JanusGraph topic of interest (production use case, technical discussion, tips & tricks, etc.), please reply back here or send me an email with your proposed topic. You can see a recording of the previous meetup here: https://vimeo.com/327767151.

Thanks!
Ted


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:

13:30:38 ERROR org.apache.spark.SparkContext  - Error initializing SparkContext.org.apache.spark.SparkException: Unable to load YARN support

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:

Hey Florian,

I was looking at the changelog for Tinkerpop 3.4.2 and saw a couple of improvements that look really nice. 

  • Changed :> in Gremlin Console to submit the client-side timeout on each request.
  • Added option to set per-request settings on a Traversal submitted via Bytecode.

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:
Hi,

now that 0.2.3 is released and 0.3.2 comes closer to a state where it can be released, I want to start the discussion for the 0.4.0 release. It will be a major release with a substantial number of contributions, considering that the last release from master was in October (0.3.1).

Some major new changes in v0.4.0:
  • Upgrade to TinkerPop 3.4.1.
  • Support CQL for OLAP which completes our CQL support.
  • Performance improvements for pre-fetching of properties.
  • Dropped support for deprecated backend versions.
The release milestone can be found here. It currently contains 2 open PRs and 5 issues. The issues are:
  • #915: Support HBase 2.0
  • #1513: Add instructions for opting out from codacy notifications
  • #734: Add systemd unit file
  • #1540: Create noarch rpm spec for rpm creation
  • #1541: Create documentation and scripts to create deb packages
The upgrade to support HBase 2.0 seems to be quite a big task and considering that it has been already 8 months since the last release of JanusGraph from master, I suggest that we don't let this delay the 0.4.0 release. We can just support HBase 2.0 in a subsequent 0.4.x release or release 0.5.0 in a few months if we need a major version bump for this.
The other open issues seem to me like they can basically be addressed in any release. I'm therefore inclined to move them to the v0.4.x milestone so they don't delay any release. If someone provides a PR for one of them shortly, we can still include them in 0.4.0 and otherwise they can land in 0.4.1 or 0.4.2.

My plan is to release 0.4.0 soon after 0.3.2, so I will probably continue with the release preparations when we have a VOTE thread for 0.3.2.

Are there any concerns with this plan? Please share any feedback you might have in general.

Regards,
Florian


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. 

  • Changed :> in Gremlin Console to submit the client-side timeout on each request.
  • Added option to set per-request settings on a Traversal submitted via Bytecode.

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:
Hi,

now that 0.2.3 is released and 0.3.2 comes closer to a state where it can be released, I want to start the discussion for the 0.4.0 release. It will be a major release with a substantial number of contributions, considering that the last release from master was in October (0.3.1).

Some major new changes in v0.4.0:
  • Upgrade to TinkerPop 3.4.1.
  • Support CQL for OLAP which completes our CQL support.
  • Performance improvements for pre-fetching of properties.
  • Dropped support for deprecated backend versions.
The release milestone can be found here. It currently contains 2 open PRs and 5 issues. The issues are:
  • #915: Support HBase 2.0
  • #1513: Add instructions for opting out from codacy notifications
  • #734: Add systemd unit file
  • #1540: Create noarch rpm spec for rpm creation
  • #1541: Create documentation and scripts to create deb packages
The upgrade to support HBase 2.0 seems to be quite a big task and considering that it has been already 8 months since the last release of JanusGraph from master, I suggest that we don't let this delay the 0.4.0 release. We can just support HBase 2.0 in a subsequent 0.4.x release or release 0.5.0 in a few months if we need a major version bump for this.
The other open issues seem to me like they can basically be addressed in any release. I'm therefore inclined to move them to the v0.4.x milestone so they don't delay any release. If someone provides a PR for one of them shortly, we can still include them in 0.4.0 and otherwise they can land in 0.4.1 or 0.4.2.

My plan is to release 0.4.0 soon after 0.3.2, so I will probably continue with the release preparations when we have a VOTE thread for 0.3.2.

Are there any concerns with this plan? Please share any feedback you might have in general.

Regards,
Florian


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:
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

--
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 janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/ccc4740b-6223-49af-b5e1-21920f3d570f%40googlegroups.com.

441 - 460 of 1596