Date
1 - 13 of 13
pr branches
Jason Plurad <plu...@...>
Now that we have v0.1.0 out the door, how do we handle the PRs in the queue? For ones that should be eligible for the 0.1 fix branch, should we request that the contributor retargets them to `0.1` branch rather than `master`? I'd think that the merge strategy would be to merge the PR into `0.1` and then from `0.1` into `master`.
Thoughts?
-- Jason
Misha Brukman <mbru...@...>
On a related note, should we make a new 0.2 branch and make it the default for new PRs going forward? Or would we go on master until we're ready for a 0.2.0 release, and then make this switch?
On Mon, Apr 24, 2017 at 12:12 PM, Jason Plurad <plu...@...> wrote:
Now that we have v0.1.0 out the door, how do we handle the PRs in the queue? For ones that should be eligible for the 0.1 fix branch, should we request that the contributor retargets them to `0.1` branch rather than `master`? I'd think that the merge strategy would be to merge the PR into `0.1` and then from `0.1` into `master`.--Thoughts?-- Jason
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.
sjudeng <sju...@...>
The merge strategy you mentioned (PR->0.1->master) makes sense to me. Another question is what to retarget to 0.1. Personally unless there are any major issues with 0.1.0 I'd prefer to focus on moving towards 0.2.0. Bug/documentation fixes make sense for 0.1 but beyond that I'd hesitate if it requires any additional work (e.g. conflicts). So things like #170, #192, #193, #208, #227, etc. might be okay but likely not #219 and #223 because of conflicts with ES updates in master. Do we see maintaining 0.1 for the long term or trying to get user's migrated to 0.2?
Misha Can we keep 0.2 development on master until we're able to more easily (e.g. without a PR/approval) merge between release branches and master?
Misha Can we keep 0.2 development on master until we're able to more easily (e.g. without a PR/approval) merge between release branches and master?
Henry Saputra <henry....@...>
One way is to have all PRs just go to master bc for now master is open for development.
When we want to do 0.2 branch then it should create branch from master to create the release.
Another way is to follow develop branch model: http://nvie.com/posts/a-successful-git-branching-model/
Using master dev for new branch development very similar to most ASF projects AFAIK.
- Henry
On Mon, Apr 24, 2017 at 5:17 PM, sjudeng <sju...@...> wrote:
The merge strategy you mentioned (PR->0.1->master) makes sense to me. Another question is what to retarget to 0.1. Personally unless there are any major issues with 0.1.0 I'd prefer to focus on moving towards 0.2.0. Bug/documentation fixes make sense for 0.1 but beyond that I'd hesitate if it requires any additional work (e.g. conflicts). So things like #170, #192, #193, #208, #227, etc. might be okay but likely not #219 and #223 because of conflicts with ES updates in master. Do we see maintaining 0.1 for the long term or trying to get user's migrated to 0.2?
Misha Can we keep 0.2 development on master until we're able to more easily (e.g. without a PR/approval) merge between release branches and master?--
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.
Jerry He <jerr...@...>
Looks good to me. It makes more sense now to target new PRs to the master, and only cherry pick when needed to the 0.1 branch, which will probably be a small subset of the PRs.
Thanks
Jerry
On Mon, Apr 24, 2017 at 6:20 PM Henry Saputra <henry....@...> wrote:
One way is to have all PRs just go to master bc for now master is open for development.When we want to do 0.2 branch then it should create branch from master to create the release.Another way is to follow develop branch model: http://nvie.com/posts/a-successful-git-branching-model/Using master dev for new branch development very similar to most ASF projects AFAIK.- Henry--On Mon, Apr 24, 2017 at 5:17 PM, sjudeng <sju...@...> wrote:The merge strategy you mentioned (PR->0.1->master) makes sense to me. Another question is what to retarget to 0.1. Personally unless there are any major issues with 0.1.0 I'd prefer to focus on moving towards 0.2.0. Bug/documentation fixes make sense for 0.1 but beyond that I'd hesitate if it requires any additional work (e.g. conflicts). So things like #170, #192, #193, #208, #227, etc. might be okay but likely not #219 and #223 because of conflicts with ES updates in master. Do we see maintaining 0.1 for the long term or trying to get user's migrated to 0.2?
Misha Can we keep 0.2 development on master until we're able to more easily (e.g. without a PR/approval) merge between release branches and master?--
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 janusgr...@....
For more options, visit https://groups.google.com/d/optout.
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 janusgr...@....
For more options, visit https://groups.google.com/d/optout.
Henry Saputra <henry....@...>
Yes, those fixes will be considered as hotfixes to create 0.1.X releases.
But in general, new devs will happen on master and new releases will branching out from master.
- Henry
On Mon, Apr 24, 2017 at 8:12 PM, Jerry He <jerr...@...> wrote:
Looks good to me. It makes more sense now to target new PRs to the master, and only cherry pick when needed to the 0.1 branch, which will probably be a small subset of the PRs.ThanksJerryOn Mon, Apr 24, 2017 at 6:20 PM Henry Saputra <henry....@...> wrote:One way is to have all PRs just go to master bc for now master is open for development.When we want to do 0.2 branch then it should create branch from master to create the release.Another way is to follow develop branch model: http://nvie.com/posts/a-successful-git-branching- model/ Using master dev for new branch development very similar to most ASF projects AFAIK.- Henry--On Mon, Apr 24, 2017 at 5:17 PM, sjudeng <sju...@...> wrote:The merge strategy you mentioned (PR->0.1->master) makes sense to me. Another question is what to retarget to 0.1. Personally unless there are any major issues with 0.1.0 I'd prefer to focus on moving towards 0.2.0. Bug/documentation fixes make sense for 0.1 but beyond that I'd hesitate if it requires any additional work (e.g. conflicts). So things like #170, #192, #193, #208, #227, etc. might be okay but likely not #219 and #223 because of conflicts with ES updates in master. Do we see maintaining 0.1 for the long term or trying to get user's migrated to 0.2?
Misha Can we keep 0.2 development on master until we're able to more easily (e.g. without a PR/approval) merge between release branches and master?--
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.
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.
sjudeng <sju...@...>
To get us moving again merging PRs I'm okay with merging into master and cherry-picking into 0.1 as needed. To accommodate this I'd recommend we enforce the one-commit per PR/feature rule, at least for any update that we may want to cherry pick into 0.1.
I think there still needs to be a decision on what to backport into 0.1. If the approach is to merge as much as possible into 0.1 then I think the cherry-pick process might become cumbersome, but we can try it out and see how it goes.
I think there still needs to be a decision on what to backport into 0.1. If the approach is to merge as much as possible into 0.1 then I think the cherry-pick process might become cumbersome, but we can try it out and see how it goes.
Henry Saputra <henry....@...>
We could probably label Github issues with 0.1 to indicate it needs porting to 0.1 branch. Then, all PR should refer to the issue filed to make sure we could manage back porting changes to 0.1 branch.
As for One-commit per PR maintainer could Squash before merge to make sure it is only one commit. We could also ask PR author to squash once all reviews are done.
- Henry
On Thu, Apr 27, 2017 at 8:37 AM, sjudeng <sju...@...> wrote:
To get us moving again merging PRs I'm okay with merging into master and cherry-picking into 0.1 as needed. To accommodate this I'd recommend we enforce the one-commit per PR/feature rule, at least for any update that we may want to cherry pick into 0.1.
I think there still needs to be a decision on what to backport into 0.1. If the approach is to merge as much as possible into 0.1 then I think the cherry-pick process might become cumbersome, but we can try it out and see how it goes.--
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.
amcp...@...
I think I've created 3 PR against 0.1 branch.
This one is already merged:
https://github.com/JanusGraph/janusgraph/pull/240
These two are not merged yet:
https://github.com/JanusGraph/janusgraph/pull/247
https://github.com/JanusGraph/janusgraph/pull/248
I just saw this thread on the dev list.
Since tests have run and already approved, OK to merge the above two to 0.1, and then cherry-pick all three above to master?
I will base any remaining changes I need to make on master, and then cherry pick to 0.1 going forwards.
Alex
On Friday, April 28, 2017 at 9:43:44 AM UTC+9, sjudeng wrote:
Sounds like a good plan to me
Alexander Patrikalakis <amcpatr...@...>
I've already posted 3 PRs to 0.1, one is merged and the two new ones are not.
However, the two new ones are approved and tests already run. OK to merge those and cherry pick to master.
Any new PR I originate will be based off master and will cherry pick into 0.1 as needed.
On Friday, April 28, 2017 at 9:43:44 AM UTC+9, sjudeng wrote:
Sounds like a good plan to me
Jason Plurad <plu...@...>
I started this thread based on the TinkerPop model, but the approach to cherry-pick fixes back into 0.1 branch sounds great to me. If we minimize the fixes going into 0.1, then we can encourage the community to move along with the latest code as much as possible.
-- Jason
On Sunday, April 30, 2017 at 5:33:55 PM UTC-4, Alex Patrikalakis wrote:
I think I've created 3 PR against 0.1 branch.This one is already merged:These two are not merged yet:I just saw this thread on the dev list.Since tests have run and already approved, OK to merge the above two to 0.1, and then cherry-pick all three above to master?I will base any remaining changes I need to make on master, and then cherry pick to 0.1 going forwards.Alex
On Friday, April 28, 2017 at 9:43:44 AM UTC+9, sjudeng wrote:Sounds like a good plan to me