Date   

Re: [DISCUSS] 0.1.0 Release Prep

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

Thanks for weighing in Florian.  I went ahead and created a new 0.2.0 milestone and moved the non-essentials for 0.1.0 that we identified over.  That leaves #102 (version compatibility matrix) and #171.  I realize we may end up having minor releases (0.1.1, etc.) but figured for now I'd just move the carryovers into 0.2.0 and we can readjust later as needed.

Thanks,
Ted

On Thursday, March 30, 2017 at 9:27:50 AM UTC-7, Florian Hockmann wrote:
I agree with your assessment of the issues for the first release which basically comes down to the conclusion that only #171 has to be resolved for the release if I didn't miss anything. (Assuming that #120 isn't seen as a show stopper as the documentation was already unclear for Titan in that regard.)

Therefore I hope that #171 can be quickly resolved so that we have a first official release. (Unfortunately I cannot provide any input there as I never worked with BerkleyDB.) But in case that #171 takes longer to be resolved I would highly appreciate another snapshot release as the current release branch probably resembles already the final release for everything apart for the BerkleyDB storage backend. The current snapshot is probably not an option for most people to upgrade from Titan as it is not backwards compatible when using Cassandra as the storage backend (due to missing changes from #80).

Am Sonntag, 26. März 2017 21:09:06 UTC+2 schrieb Ted Wilmes:
Nice summary and I'm in agreement with the ones you've marked to remove from the milestone.
In addition, I think #120 could be pushed.  These are all important, but I do not think critical, for the 
first release.  I'm also in agreement that #171 should be added.  I saw your note on that and I'll take
a look at it too.

--Ted

On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
Thanks for getting the ball rolling on this. Below are my recommendations based on 0.1.0 being scoped as an initial compatibility release to enable the easiest possible Titan->JanusGraph transition. In this case no new features are really required.

#41 TinkerPop 3.2 upgrade (status: closed)
- I closed this issue assuming it's reasonable to tie it to the upgrade to 3.2.3 and opened a new issue for the update to 3.2.4, which in my opinion isn't a blocker for the 0.1.0 release. It is worth noting though that JanusGraph TinkerPop tests do require a TinkerPop commit that is not in 3.2.3. I recommend making a temporary note of the workaround steps for this in documentation (e.g. BUILDING.md), which could be removed after updating to 3.2.4.

#74 Automated testing in Travis (remove from 0.1.0 milestone)
- I think it's important that all tests (including TinkerPop tests) are run on the release candidate, but I don't think it's necessary for this to be fully automated through Travis.

#120 Improve documentation of ids.num-partitions
- I can go either way on this one.

#128 Dependency license check in Travis (remove from 0.1.0 milestone)
- Like testing this check could be manual for 0.1.0.

#132 Non-permissive licenses in dependencies (remove from 0.1.0 milestone)
- From a user perspective these dependencies have been there since Titan and have not been added by JanusGraph. The only issue would be if there are additional restrictions on JanusGraph as a Linux Foundation project.

#133 Mark JTS optional in janusgraph-solr (remove from 0.1.0 milestone)
- Same as #132 above.

#147 Support custom ids (remove from 0.1.0 milestone)
- I don't think we're close on this and it's definitely a new feature (or a long outstanding bug?)

#171 Test failures in janusgraph-berkeleyje (add to 0.1.0 milestone)
- I think all tests need to pass for a release.


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

A PR has been submitted to resolve #171. With this update all core and TinkerPop tests are passing on all modules in the jg01 branch.

I propose adding #182 (Travis CI on release branch) and #184 (release documentation updates) to the milestone. Both these issues are associated with open PRs.

I also recommend we add relevant closed issues/PRs to the 0.1.0 milestone. The changelog will include a reference to the milestone GitHub page so I think it'll useful if this provides as complete a picture as possible on updates included in the release. Minor updates (documentation/etc.) are probably not necessary to include but others (HBase/BerkeleyJE upgrades, Google Big Table support, etc.) should probably be added.


Re: [DISCUSS] 0.1.0 Release Prep

Misha Brukman <mbru...@...>
 

Sorry I'm late to the party, but can we change the branch name strategy? Presumably, these branch names will be long-lived (we will have patch releases) and folks will want to see these in the future, so I'd like to make sure they're readable, unique, and meaningful.

I'd like to propose the following:
  • branch name: 0.1.x (literally), 0.2.x, etc. — the 'x' is the wildcard since the branch will move forward; no need for a "jg" prefix (we know what the project name is), and we should include the dots to separate major vs. minor vs. patch (see below as to why)
  • release tags: 0.1.0, 0.1.1, etc. — specific versions, no wild cards, these are meant to be fixed-in-place
  • release candidates / snapshots: 0.1.0-rc1, 0.1.0-rc2 — I know I earlier proposed 0.1.0-SNAPSHOT-<date> and I'm retracting it, having seen that this is what several Apache projects are ding, and I find it's more meaningful, simpler, and shorter
These will be directly visible in the URLs, e.g., https://github.com/janusgraph/janusgraph/tree/0.1.0/... as well as when we suggest a user check out a specific tag or branch, it's in the command line. It's much easier if this is meaningful, easily readable version id. Using a pattern such as "jg01" means we'll use "jg10" for 1.0, but what will 10.0 use? "jg10" vs. "jg100" will be very confusing.

Or, if we go to 0.11 (hypothetically), that would be "jg011" but what if we also have 0.1.1? That would also be "jg011" using this model.

Thoughts?

On Sun, Mar 26, 2017 at 12:11 PM, Ted Wilmes <twi...@...> wrote:
Hello,
I have created a release branch (jg01) we can use for 0.1.0 prep.  I think at this point we're ready to discuss what will go into 0.1.0.  Open issues
tagged for the 0.1.0 milestone can be seen at https://github.com/JanusGraph/janusgraph/milestone/1.

Should the TinkerPop upgrade issue #41 be closed out at this point Sjudeng since you guys completed the 3.2.3 upgrade?  I think 
#73 Titan Compatibility can probably be closed as the related PR has been merged.  That leaves 6 more outstanding issues.  Which of these
would you all like to see included for sure versus what could be pushed?  Are there any additional issues that are not tagged for 0.1.0 that
should be?  I could see #171 being one possibility.

Thanks,
Ted


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] 0.1.0 Release Prep

Jerry He <jerr...@...>
 

Thanks for the work, Ted, sjudeng.

I am good with what you suggested, Misha.

0.1.x (literally), 0.2.x

There is no need to have the 'x' though.  0.1 is the minor release branch line and will move forward.

Thanks.

Jerry


On Saturday, April 1, 2017 at 8:59:49 PM UTC-7, Misha Brukman wrote:
Sorry I'm late to the party, but can we change the branch name strategy? Presumably, these branch names will be long-lived (we will have patch releases) and folks will want to see these in the future, so I'd like to make sure they're readable, unique, and meaningful.

I'd like to propose the following:
  • branch name: 0.1.x (literally), 0.2.x, etc. — the 'x' is the wildcard since the branch will move forward; no need for a "jg" prefix (we know what the project name is), and we should include the dots to separate major vs. minor vs. patch (see below as to why)
  • release tags: 0.1.0, 0.1.1, etc. — specific versions, no wild cards, these are meant to be fixed-in-place
  • release candidates / snapshots: 0.1.0-rc1, 0.1.0-rc2 — I know I earlier proposed 0.1.0-SNAPSHOT-<date> and I'm retracting it, having seen that this is what several Apache projects are ding, and I find it's more meaningful, simpler, and shorter
These will be directly visible in the URLs, e.g., https://github.com/janusgraph/janusgraph/tree/0.1.0/... as well as when we suggest a user check out a specific tag or branch, it's in the command line. It's much easier if this is meaningful, easily readable version id. Using a pattern such as "jg01" means we'll use "jg10" for 1.0, but what will 10.0 use? "jg10" vs. "jg100" will be very confusing.

Or, if we go to 0.11 (hypothetically), that would be "jg011" but what if we also have 0.1.1? That would also be "jg011" using this model.

Thoughts?

On Sun, Mar 26, 2017 at 12:11 PM, Ted Wilmes <t...@...> wrote:
Hello,
I have created a release branch (jg01) we can use for 0.1.0 prep.  I think at this point we're ready to discuss what will go into 0.1.0.  Open issues
tagged for the 0.1.0 milestone can be seen at https://github.com/JanusGraph/janusgraph/milestone/1.

Should the TinkerPop upgrade issue #41 be closed out at this point Sjudeng since you guys completed the 3.2.3 upgrade?  I think 
#73 Titan Compatibility can probably be closed as the related PR has been merged.  That leaves 6 more outstanding issues.  Which of these
would you all like to see included for sure versus what could be pushed?  Are there any additional issues that are not tagged for 0.1.0 that
should be?  I could see #171 being one possibility.

Thanks,
Ted


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] 0.1.0 Release Prep

Misha Brukman <mbru...@...>
 

On Sun, Apr 2, 2017 at 12:26 AM, Jerry He <jerr...@...> wrote:
I am good with what you suggested, Misha.

0.1.x (literally), 0.2.x

There is no need to have the 'x' though.  0.1 is the minor release branch line and will move forward.

I think we need to explicitly differentiate movable pointers (release branches) vs. static pointers (specific version tags).

One proposal is what I shared earlier: 0.1.x (branches) and 0.1.1 (version tags). My concern is that 0.1 (branch) vs. 0.1.0 (release tag) is insufficiently different as to be confusing which is movable vs. static.

Here are some alternatives from a couple Apache projects:
  • Storm uses "0.1.0" (branch) and "v0.1.0" (tag) — essentially what Jerry is proposing (with a "v" prefix for version tags)
  • Zeppelin uses "branch-0.5" (branch) and "v0.5.1" (tag) — verbose
  • Toree (incubating) uses "0.1.x" and "v0.1.2" (tag) — essentially what I proposed
  • HBase uses "0.18" (branch) and "release-0.1" or "rel/0.1" (tags) — verbose
  • Cassandra uses "cassandra-0.1" for both branches and tags — seems confusing
Taking Jerry's suggestion and Storm's approach of differentiating the branches vs. tags, we can do the following:
  • branches: 0.1, 0.2, etc. — no wildcard
  • version tags: v0.1.0 — 'v' prefix
  • release candidates: v0.1-rc1 — 'v' prefix, 'rc#' suffix
Any objections?

Misha


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

This sounds good to me. Would the release candidate be 0.1.0-rc1 instead of 0.1-rc1?

Another related question is whether or not to target release features on the release branch or master. I've been targeting 0.1.0 features on the release branch with the understanding that we can and should be regularly merging the release branch into master. This model of merging relevant features into release branches and then merging release branches into master is what TinkerPop does (see merge commits on https://github.com/apache/tinkerpop/commits/master).


Re: [DISCUSS] 0.1.0 Release Prep

Jerry He <jerr...@...>
 

+1 on the new proposal.

Thanks.

Jerry

On Saturday, April 1, 2017 at 9:48:41 PM UTC-7, Misha Brukman wrote:
On Sun, Apr 2, 2017 at 12:26 AM, Jerry He <je...@...> wrote:
I am good with what you suggested, Misha.

0.1.x (literally), 0.2.x

There is no need to have the 'x' though.  0.1 is the minor release branch line and will move forward.

I think we need to explicitly differentiate movable pointers (release branches) vs. static pointers (specific version tags).

One proposal is what I shared earlier: 0.1.x (branches) and 0.1.1 (version tags). My concern is that 0.1 (branch) vs. 0.1.0 (release tag) is insufficiently different as to be confusing which is movable vs. static.

Here are some alternatives from a couple Apache projects:
  • Storm uses "0.1.0" (branch) and "v0.1.0" (tag) — essentially what Jerry is proposing (with a "v" prefix for version tags)
  • Zeppelin uses "branch-0.5" (branch) and "v0.5.1" (tag) — verbose
  • Toree (incubating) uses "0.1.x" and "v0.1.2" (tag) — essentially what I proposed
  • HBase uses "0.18" (branch) and "release-0.1" or "rel/0.1" (tags) — verbose
  • Cassandra uses "cassandra-0.1" for both branches and tags — seems confusing
Taking Jerry's suggestion and Storm's approach of differentiating the branches vs. tags, we can do the following:
  • branches: 0.1, 0.2, etc. — no wildcard
  • version tags: v0.1.0 — 'v' prefix
  • release candidates: v0.1-rc1 — 'v' prefix, 'rc#' suffix
Any objections?

Misha


Opportunity to Contribute

Jainesh Patel <jaine...@...>
 

Hello everyone,

I am new to this community. Can anyone please guide me to start contributing to JanusGraph?

Any bugs to start with?

Thank you,
Jainesh Patel
Pune, India


Re: Opportunity to Contribute

Irving Duran <irvin...@...>
 

You can take a look at this for contributing -> https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTING.md and the current list of issues -> https://github.com/JanusGraph/janusgraph/issues.




Thank You,

Irving Duran

On Sun, Apr 2, 2017 at 4:22 PM, Jainesh Patel <jaine...@...> wrote:
Hello everyone,

I am new to this community. Can anyone please guide me to start contributing to JanusGraph?

Any bugs to start with?

Thank you,
Jainesh Patel
Pune, India

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

Are there any other issues not in the milestone we need to add for 0.1.0? I can see #132 (onc/rpc dependency exclusion).

The branch as it is now (with #179 merged) is fully tested including core and TinkerPop tests. All other issues currently in the milestone are documentation updates, which aren't a worry in terms of stability/testing. Also I don't think #132 would impact testing (Jason, are there any metrics tests that might be affected?). If we can refrain from adding any more code updates then I think we can move out without further (unit) testing on the 0.1.0 release pending merge of #179 (and maybe #132) and review/merge of the documentation updates (#102, #177, #184).

Ted I assume you'll be the RM on the 0.1.0 release?


Re: [DISCUSS] 0.1.0 Release Prep

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

#179 looks good to me and now has 2 +1's.  I'll merge it.  I'd been slow playing the RM thing...but I'll give it a shot barring anyone else jumping up enthusiastically requesting the position.  I would not be offended :)

So branch-wise, at this point, consensus is jg01 should be changed to 0.1?

Thanks,
Ted

On Mon, Apr 3, 2017 at 9:11 AM, sjudeng <sju...@...> wrote:
Are there any other issues not in the milestone we need to add for 0.1.0? I can see #132 (onc/rpc dependency exclusion).

The branch as it is now (with #179 merged) is fully tested including core and TinkerPop tests. All other issues currently in the milestone are documentation updates, which aren't a worry in terms of stability/testing. Also I don't think #132 would impact testing (Jason, are there any metrics tests that might be affected?). If we can refrain from adding any more code updates then I think we can move out without further (unit) testing on the 0.1.0 release pending merge of #179 (and maybe #132) and review/merge of the documentation updates (#102, #177, #184).

Ted I assume you'll be the RM on the 0.1.0 release?

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/YLnWWeNi0Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] 0.1.0 Release Prep

Jason Plurad <plu...@...>
 

@sjudeng, no I didn't see any metrics tests that would be affected by #132.

I'd like to see mitigation of the LGPL for the JTS dependency #133 go in also. I looked around at some other projects: Apache Ignite uses a Maven profile to handle it, and Elasticsearch marks it as optional.

@Ted +1 on the branch rename jg01 -> 0.1

On Monday, April 3, 2017 at 10:11:44 AM UTC-4, sjudeng wrote:
Are there any other issues not in the milestone we need to add for 0.1.0? I can see #132 (onc/rpc dependency exclusion).

The branch as it is now (with #179 merged) is fully tested including core and TinkerPop tests. All other issues currently in the milestone are documentation updates, which aren't a worry in terms of stability/testing. Also I don't think #132 would impact testing (Jason, are there any metrics tests that might be affected?). If we can refrain from adding any more code updates then I think we can move out without further (unit) testing on the 0.1.0 release pending merge of #179 (and maybe #132) and review/merge of the documentation updates (#102, #177, #184).

Ted I assume you'll be the RM on the 0.1.0 release?


Re: [DISCUSS] Splitting janusgraph-cassandra

Jason Plurad <plu...@...>
 

Bump. I think the breakdown is fine. It looks similar to what's going on in the janusgraph-hbase directory.

I'd suggest that the root remains `janusgraph-cassandra` rather than `cassandra` as your repo has it.


On Sunday, March 26, 2017 at 10:11:48 PM UTC-4, Samant Maharaj wrote:
Hi,

As part of implementing the janusgraph-cql backend, we initially looked into adding the new CQL backend into the existing janusgraph-cassandra project.

We ultimately ended up not taking this approach because it would mean that any code depending on the CQL backend would still end up pulling cassandra-all, astyanax and all their dependencies which is quite undesirable.

We'd like to know what everyone thinks of the idea of splitting janusgraph-cassandra into core and implementation specific modules. If we implemented this, CQL could be moved in as another backend without any unrelated dependencies.

I've implemented this change in a branch in our repository here: https://github.com/orionhealth/janusgraph/tree/feature/cassandra-refactor

Some notes:
  • This covers all the existing backends but not the port of the CQL backend to the new structure.
  • We've simplified the testing setup code around bootstrapping Cassandra which enables running the tests easily from your IDE. It also removes the current dependency on inter-project structure where the other projects need to know how to use the resources in janusgraph-cassandra to bootstrap Cassandra.
  • We've introduced a cassandra-test project that is included in test scope similar to janusgraph-test that contains the shared testing code.
Samant Maharaj & Paul Kendall


Re: [DISCUSS] Splitting janusgraph-cassandra

Samant Maharaj <samant...@...>
 

The reason for the simplified naming was to avoid nested modules having quite long names.

For example, the nested astyanax module would be called 'janusgraph-cassandra-astyanax'.

The other issue is that following that convention, the janusgraph-cassandra artifactId would now actually refer to the parent POM of all the cassandra modules which would conflict with its earlier incarnation. The other way to resolve this would be to call it 'janugraph-cassandra-parent' similar to hbase and hadoop. However this is quite an unconventional approach.

Personally I'm in favour of a less verbose naming scheme but it's not something I'm too concerned about.


On Wednesday, 5 April 2017 02:26:05 UTC+12, Jason Plurad wrote:
Bump. I think the breakdown is fine. It looks similar to what's going on in the janusgraph-hbase directory.

I'd suggest that the root remains `janusgraph-cassandra` rather than `cassandra` as your repo has it.

On Sunday, March 26, 2017 at 10:11:48 PM UTC-4, Samant Maharaj wrote:
Hi,

As part of implementing the janusgraph-cql backend, we initially looked into adding the new CQL backend into the existing janusgraph-cassandra project.

We ultimately ended up not taking this approach because it would mean that any code depending on the CQL backend would still end up pulling cassandra-all, astyanax and all their dependencies which is quite undesirable.

We'd like to know what everyone thinks of the idea of splitting janusgraph-cassandra into core and implementation specific modules. If we implemented this, CQL could be moved in as another backend without any unrelated dependencies.

I've implemented this change in a branch in our repository here: https://github.com/orionhealth/janusgraph/tree/feature/cassandra-refactor

Some notes:
  • This covers all the existing backends but not the port of the CQL backend to the new structure.
  • We've simplified the testing setup code around bootstrapping Cassandra which enables running the tests easily from your IDE. It also removes the current dependency on inter-project structure where the other projects need to know how to use the resources in janusgraph-cassandra to bootstrap Cassandra.
  • We've introduced a cassandra-test project that is included in test scope similar to janusgraph-test that contains the shared testing code.
Samant Maharaj & Paul Kendall


Re: [DISCUSS] Splitting janusgraph-cassandra

Alexander Patrikalakis <amcpatr...@...>
 

Yeah, we can't reuse the janusgraph-cassandra artifact id.


On Wednesday, April 5, 2017 at 5:03:20 AM UTC+9, Samant Maharaj wrote:
The reason for the simplified naming was to avoid nested modules having quite long names.

For example, the nested astyanax module would be called 'janusgraph-cassandra-astyanax'.

The other issue is that following that convention, the janusgraph-cassandra artifactId would now actually refer to the parent POM of all the cassandra modules which would conflict with its earlier incarnation. The other way to resolve this would be to call it 'janugraph-cassandra-parent' similar to hbase and hadoop. However this is quite an unconventional approach.

Personally I'm in favour of a less verbose naming scheme but it's not something I'm too concerned about.

On Wednesday, 5 April 2017 02:26:05 UTC+12, Jason Plurad wrote:
Bump. I think the breakdown is fine. It looks similar to what's going on in the janusgraph-hbase directory.

I'd suggest that the root remains `janusgraph-cassandra` rather than `cassandra` as your repo has it.

On Sunday, March 26, 2017 at 10:11:48 PM UTC-4, Samant Maharaj wrote:
Hi,

As part of implementing the janusgraph-cql backend, we initially looked into adding the new CQL backend into the existing janusgraph-cassandra project.

We ultimately ended up not taking this approach because it would mean that any code depending on the CQL backend would still end up pulling cassandra-all, astyanax and all their dependencies which is quite undesirable.

We'd like to know what everyone thinks of the idea of splitting janusgraph-cassandra into core and implementation specific modules. If we implemented this, CQL could be moved in as another backend without any unrelated dependencies.

I've implemented this change in a branch in our repository here: https://github.com/orionhealth/janusgraph/tree/feature/cassandra-refactor

Some notes:
  • This covers all the existing backends but not the port of the CQL backend to the new structure.
  • We've simplified the testing setup code around bootstrapping Cassandra which enables running the tests easily from your IDE. It also removes the current dependency on inter-project structure where the other projects need to know how to use the resources in janusgraph-cassandra to bootstrap Cassandra.
  • We've introduced a cassandra-test project that is included in test scope similar to janusgraph-test that contains the shared testing code.
Samant Maharaj & Paul Kendall


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

The release branch has been renamed to 0.1 with relevant PRs retargeted. There's also an open PR to merge 0.1 into master. It would be nice if merging from release branches into master (or other release branches) didn't require the additional redundant review.

I'll look at #133 unless someone else is already on it.


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

Misha, Shouldn't there be a distinction between snapshot releases and release candidates? In general snapshot releases like the one out there now may not be fully stable and well tested or have all features agreed upon for a formal release. On the other hand I thought we'd have a 0.1.0-RC1 when we're ready to call a vote on the 0.1.0 release, so that would be more stable and well vetted.


Re: [DISCUSS] 0.1.0 Release Prep

Henry Saputra <henry....@...>
 

@jason But should not be a blocker for 0.1 release I suppose ?


On Tuesday, April 4, 2017 at 7:22:25 AM UTC-7, Jason Plurad wrote:
@sjudeng, no I didn't see any metrics tests that would be affected by #132.

I'd like to see mitigation of the LGPL for the JTS dependency #133 go in also. I looked around at some other projects: Apache Ignite uses a Maven profile to handle it, and Elasticsearch marks it as optional.

@Ted +1 on the branch rename jg01 -> 0.1

On Monday, April 3, 2017 at 10:11:44 AM UTC-4, sjudeng wrote:
Are there any other issues not in the milestone we need to add for 0.1.0? I can see #132 (onc/rpc dependency exclusion).

The branch as it is now (with #179 merged) is fully tested including core and TinkerPop tests. All other issues currently in the milestone are documentation updates, which aren't a worry in terms of stability/testing. Also I don't think #132 would impact testing (Jason, are there any metrics tests that might be affected?). If we can refrain from adding any more code updates then I think we can move out without further (unit) testing on the 0.1.0 release pending merge of #179 (and maybe #132) and review/merge of the documentation updates (#102, #177, #184).

Ted I assume you'll be the RM on the 0.1.0 release?


Re: [DISCUSS] Splitting janusgraph-cassandra

sjudeng <sju...@...>
 

Samant & Paul,

Thanks for your work on this. I like what you've done to clean up the project configs in the other modules in favor of the cassandra-test module.

I do agree that for consistency it would be best to include the janusgraph- prefix in the artifact id, at least for the base cassandra module. Whether it can be janusgraph-cassandra or needs to be janusgraph-cassandra-parent, I don't know. Since presumably you'll retarget to 0.2.0-SNAPSHOT, as long as there are no 0.2.0 snapshot deployments before your PR gets merged, wouldn't it be fine to reuse janusgraph-cassandra in this new context?

Also what about making the groupId org.janusgraph.cassandra for the sub-modules (core, embedded, etc.)? I'm just thinking of the eventual repository layout (see https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/) and wondering if it would be better organization to group the sub-modules under the additional cassandra group element.


Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

I added #133 back to the 0.1.0 milestone and created PR #189 to resolve it. It already has one approval so we just need one more for merge. The other two issues in the milestone are addressed by PRs #176 and #185. Both of these have requested changes that have been addressed, so once reviewers are able to acknowledge and approve those changes we'll be set.

121 - 140 of 1585