[DISCUSS] 0.1.1 point fix release


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

I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


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

That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted


On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


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

Its a related change because the meaning of ID_STORE_NAME is no longer static:
https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR333
getting pulled from config instead, so had to move away from static init.


On Wednesday, May 3, 2017 at 10:48:31 PM UTC+9, Ted Wilmes wrote:
That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted

On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


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

With the release process being better understood now that we've done one, a 72 hour voting period sounds fine.


On Wednesday, May 3, 2017 at 12:45:58 PM UTC-4, Alexander Patrikalakis wrote:
Its a related change because the meaning of ID_STORE_NAME is no longer static:
getting pulled from config instead, so had to move away from static init.

On Wednesday, May 3, 2017 at 10:48:31 PM UTC+9, Ted Wilmes wrote:
That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted

On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


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

+1


Rafael Fernandes <luizr...@...>
 

+1


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

Sounds like folks are in agreement. I'll run the TinkerPop tests, etc. on 0.1.1-SNAPSHOT and put together a RC and shoot for starting vote sometime Monday unless there are any objections in the meantime.

--Ted


On Wednesday, May 3, 2017 at 5:44:26 PM UTC-5, Rafael Fernandes wrote:
+1


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

I was delayed but I'm finishing up the testing. I was getting a few spurious Solr failures so I'm completing some re-runs now. I'll work on getting things bundled up after this if all is good and then start the vote.

Thanks,
Ted 


On Friday, May 5, 2017 at 8:38:45 AM UTC-5, Ted Wilmes wrote:
Sounds like folks are in agreement. I'll run the TinkerPop tests, etc. on 0.1.1-SNAPSHOT and put together a RC and shoot for starting vote sometime Monday unless there are any objections in the meantime.

--Ted

On Wednesday, May 3, 2017 at 5:44:26 PM UTC-5, Rafael Fernandes wrote:
+1


sjudeng <sju...@...>
 

FYI I had seen sporadic Solr errors ("Not enough nodes to handle the request") before as well in some testing environments, in particular in Travis. In digging into this as part of #251 (Travis build improvements) I found the issue was a bug in the detection logic around live recoveries in SolrIndex. The issue is fixed in that PR branch, though that doesn't help for this release. In the meantime I've found testing under CentOS 7 to be stable regarding these errors.


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

Thanks Sjudeng, that's exactly what I was running into. I just put a PR[1] in with the release prep, artifacts are built and staged, so close to ready for a vote. After I get a review, I can merge this and create the pre-release on github for vote.

https://github.com/JanusGraph/janusgraph/pull/269

Thanks,
Ted


On Wednesday, May 10, 2017 at 9:25:28 PM UTC-5, sjudeng wrote:
FYI I had seen sporadic Solr errors ("Not enough nodes to handle the request") before as well in some testing environments, in particular in Travis. In digging into this as part of #251 (Travis build improvements) I found the issue was a bug in the detection logic around live recoveries in SolrIndex. The issue is fixed in that PR branch, though that doesn't help for this release. In the meantime I've found testing under CentOS 7 to be stable regarding these errors.