I concur. I think we should spend ~3 weeks cleaning up our 3.2.2 chaos and do a 3.2.3 release before going down the 3.3.0 rabbit hole.
Marko. http://markorodriguez.com > On Sep 14, 2016, at 7:42 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > > I don't really like how 3.2.2 is feeling. We've had a number of bugs, > documentation holes, etc. I think we should hold off on opening the tp32 > branch a bit longer and focus on firming up these problems before anyone > worries about 3.3.x too much. Unless anyone feels differently, I'll not > look to setup tp32 this coming weekend. We can revisit moving forward on > the tp32 branch for next week. > > On Tue, Sep 13, 2016 at 8:43 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > >> While we haven't started the tp32 branch yet, I thought I'd do the dual PR >> model for a bug fix that i had on tp31 just to see how it would go. So I >> created two branches using the git commands i specified in my last post on >> this thread: >> >> TINKERPOP-1442 >> TINKERPOP-1442-master >> >> and created two PRs from them: >> >> https://github.com/apache/tinkerpop/pull/412 >> https://github.com/apache/tinkerpop/pull/413 >> >> I think it was helpful to "tag" the target branch in the PR description so >> it was easy to figure out just from the PR list which one you were looking >> at. In this case, this was a pretty easy merge situation as there wasn't >> much divergence between the branches. A nice part about this approach is >> that it forces specific testing of the integration of the code to each >> branch, so even though the code changes are pretty much identical, we are >> assured that some other difference elsewhere between the branches doesn't >> create some havoc we didn't know about. >> >> I suppose the VOTE should still occur on both PRs prior to merging. I >> think it will be confusing any other way. >> >> We will need to take care when merging CTR'd work to not inadvertently >> merge commits destined for master on a PR that is under review. I sense >> that is possible with this model. If you CTR to tp32 and attempt a merge to >> master and get "more" commits than just your CTR, you should take a closer >> look at what it is going on. I think this also means that we need to not >> merge the tp32 PR without also being ready to merge the master PR. They >> should both happen in fairly fast succession of one another. >> >> sorry - boring post - thanks for reading. >> >> On Tue, Sep 13, 2016 at 8:08 AM, Stephen Mallette <spmalle...@gmail.com> >> wrote: >> >>> 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 <m...@gremlin.guru> 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 <spmalle...@gmail.com> >>>> 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? >>>>> >>>> >>> >>> >>
