Re: [DISCUSS] 3.3.0 Branching strategy

[Stephen Mallette <sp...@gmail.com>]

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 <sp...@gmail.com>
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 <sp...@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 <sp...@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 <me...@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 <sp...@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?
>>>> >
>>>>
>>>
>>>
>>
>

Re: [DISCUSS] 3.3.0 Branching strategy

[Ted Wilmes <tw...@gmail.com>]

That sounds like a good and reasonable plan to me.

--Ted

On Sat, Oct 1, 2016, 6:10 AM Stephen Mallette <sp...@gmail.com> 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 <sp...@gmail.com>
> 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 <sp...@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 <spmallette@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 <me...@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 <
> spmallette@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?
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>