As there have been no objections, we will go with the PR per branch model when we open the tp32 branch this coming weekend. The flow is pretty simple. Let's say you have work for tp32:
1. git checkout -b <TINKERPOP-1234> tp32 2. do a bunch of stuff and commit in there 3. git checkout -b <TINKERPOP1234-master> master 4. git merge TINKERPOP-1234 That produces two branches, one for tp32 and one for master, from which you can formulate the PRs in GitHub. One issue I thought of this morning was what to do in the case of CTRs where we commit directly to tp32. In those cases, the committer should immediately merge to master as we normally do: git checkout master git merge tp32 Presumably, CTR'd work will be a single small commit that is easy to merge. I think we should try to avoid cherry-pick in this model as it re-writes history (i.e. new hash generated for the cherry-picked commit). If we need a commit to stay in tp31 there are ways to do the merge without bringing that specific commit forward. Hope that all makes sense to everyone. I'll probably add something to the dev docs about this model for when we get stated with tp32 next week. On Thu, Sep 8, 2016 at 3:47 PM, Daniel Kuppitz <[email protected]> wrote: > Sounds good to me. It won't necessarily mean much more work, since I assume > that most branches won't have any merge conflicts. > > Cheers, > Daniel > > > On Thu, Sep 8, 2016 at 6:36 PM, Stephen Mallette <[email protected]> > wrote: > > > I think 3.3.0 will be a "big" release with many breaking changes as we > > remove deprecation, upgrade certain dependencies, and make other > usability > > improvements. This won't be a release we want to rush as it affords us an > > opportunity to make a number of things a lot better. I believe that we'd > > discussed having 3.3.0 as a release for the end of 2016, but the more I > > think about it, the more I wonder if that's enough time. > > > > Anyway, I think that if we hope to get a 3.3.0 out by end of 2016 or > early > > 2017, we will need to get started sooner than later. That of course, > would > > lead us to our branching model in git and how we will want to approach > > that. > > > > Right now, things are pretty simple. We maintain master and tp31 branches > > and tp31 merges one-way to master. If we want to start work on 3.3.0, > then > > I think we should begin a tp32 branch for the 3.2.x line of code and make > > master be 3.3.x. Of course, that complicates our workflow slightly > because > > tp31 will need to merge to tp32 and then tp32 to master. While tp31 > > development has ceased with the exception of bug fixes, I already find > > divergence between tp31 and master as things stand today and that will > only > > get worse as we make breaking change to master. The point is that it may > be > > burdensome to merge tp32 to master at times for those other than the > > original author of the work being merged. > > > > We may find that we may need a multi-pull request model to cleanly deal > > with conflicts inherent to the merge. In other words, a change to tp31 > > would mean a separate pull request to tp31, tp32 and master (as opposed > to > > one pull request to tp31 with a merge at some later time to tp32 and then > > at some later time tp32 to master). For a change to tp32 you would just > do > > a PR to tp32 and a PR to master. That would be the safest way to deal > with > > conflicts and not have any surprises for some poor sap doing a blind > merge > > from one of our release branches down the line. > > > > Any thoughts on any of this? > > >
