That sounds like a good and reasonable plan to me. --Ted
On Sat, Oct 1, 2016, 6:10 AM Stephen Mallette <[email protected]> wrote: > As we are now firming up 3.2.3/3.1.5 I think we can look to move forward on > creating the tp32 branch. I will set that up the weekend that we start code > freeze. I'll also take a moment to mention that I sense that 3.3.0 will > have a big scope with breaking changes. While we've had breaking change > before, I think much of that has been quite minor compared to where we are > headed. We'll be moving classes around, killing dead code/deprecated > methods, improving/altering some behaviors, updating dependencies, etc, > (before I scare everyone to pieces, there shouldn't be be wholesale changes > to the structure API or anything like that). It will be the first of these > kinds of changes since 3.0.0 (which I'm pretty impressed with btw - 3.1.5!! > how did that happen?!) > > I had personally hoped we would see 3.3.0 by end of 2016, but given scope > and type of changes, I don't think that can happen. Instead, I suggest we > do some milestone releases for 3.3.0 until everyone catches up to our > changes and gets comfortable, while continuing to fix bugs on 3.1.x and > doing features/bugs on 3.2.x. I think milestones also provide us some > flexibility to get 3.3.0 "right" as we likely won't open up for this type > of change again for a long while to come. The milestone process worked > pretty well when we tried to get 3.0.0 out the door - maybe we won't need > as many milestones this time :) > > I hope that approach sounds good to everyone. > > Take care, > > Stephen > > > > On Fri, Sep 16, 2016 at 8:07 AM, Stephen Mallette <[email protected]> > wrote: > > > Going back to the dual PRs i referenced: > > > > https://github.com/apache/tinkerpop/pull/412 > > https://github.com/apache/tinkerpop/pull/413 > > > > After a few days of review, I noticed this morning that now that they > were > > ready for merge, they were conflicted. That means some extra steps > because > > if I had: > > > > git checkout tp31 > > git merge TINKERPOP-1442 > > > > and resolved the conflict as part of the merge then I would create a > fresh > > merge commit in tp31 which wouldn't be in master (and that would mean > that > > the next person to serve up a PR from tp31 to master would end up with > that > > commit hanging in their PR). Since there is a conflict in the PR, I need > to > > rebase: > > > > git checkout TINKERPOP-1442 > > git rebase origin/tp31 > > > > At this point, I would complete the rebase and maybe test if necessary, > > and then: > > > > git push origin TINKERPOP-1442 --force > > > > Now, git rebase has re-written my commit history which is going to hose > my > > PR to master, so we just need to clean that up: > > > > git checkout TINKERPOP-1442-master > > git reset --hard origin/master > > git merge TINKERPOP-1442 > > > > and again, re-test if necessary and force push, at which point both PRs > > can be merged cleanly. I'll write all this up in the dev docs to serve > as > > a reference. > > > > > > On Tue, Sep 13, 2016 at 8:43 PM, Stephen Mallette <[email protected]> > > 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 <[email protected] > > > >> 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 <[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? > >>>> > > >>>> > >>> > >>> > >> > > >
