Branch history fixups

["James E. King III" <jk...@apache.org>]

Our release branching strategy has left a number of loose ends.
Specifically, none of the release branches except for 0.12.0 have been
merged back into master.  Based on the way past releases were done, we
would branch off master then make a number of versioning changes which were
never intended to be merged back.  Without merging back, this leaves the
possibility that one could strand an important code change in a release
branch. It also leaves master with incomplete history.  In this type of
merge one does a "git merge --strategy-option=ours origin/<branch>" and
drops any collisions against master.

I'm going to start doing this for our release branches, ensuring the
resulting differences are negligible.  This will ensure we haven't missed
anything along the way, and GibHub will understand that a merge has already
occurred, so when we get a random pull request to merge 0.9.3 into master
(seems to happen about twice a year), there will be nothing to do.

- Jim

Re: Branch history fixups

["James E. King III" <jk...@apache.org>]

It is not uncommon to either cherry-pick a critical fix from master back
into a release branch, or to make a packaging related change to fix
language-specific packaging metadata and do it in the branch.  All release
branches should merge back into master even if they drop the version number
changes.

I completed the effort yesterday.  There were a couple minor things that
had slipped through but no code changes in that area, just some metadata.
If you look on GitHub now for branches, it'll show you that all our release
branches are zero commits ahead of master.  This means nobody can submit
those crazy merges from 0.9.3 into master any more. :)

On Wed, Jan 9, 2019 at 3:23 AM Jens Geyer <je...@hotmail.com> wrote:

> Why are there code changes in the brznch in the first place?
>
> Sent from mobile device, please ignore spelling mistakes.
> ________________________________
> Von: James E. King III
> Gesendet: 08.01.2019 16:33
> An: dev@thrift.apache.org
> Betreff: Branch history fixups
>
> Our release branching strategy has left a number of loose ends.
> Specifically, none of the release branches except for 0.12.0 have been
> merged back into master.  Based on the way past releases were done, we
> would branch off master then make a number of versioning changes which were
> never intended to be merged back.  Without merging back, this leaves the
> possibility that one could strand an important code change in a release
> branch. It also leaves master with incomplete history.  In this type of
> merge one does a "git merge --strategy-option=ours origin/<branch>" and
> drops any collisions against master.
>
> I'm going to start doing this for our release branches, ensuring the
> resulting differences are negligible.  This will ensure we haven't missed
> anything along the way, and GibHub will understand that a merge has already
> occurred, so when we get a random pull request to merge 0.9.3 into master
> (seems to happen about twice a year), there will be nothing to do.
>
> - Jim
>

AW: Branch history fixups

[Jens Geyer <je...@hotmail.com>]

Why are there code changes in the brznch in the first place?

Sent from mobile device, please ignore spelling mistakes.
________________________________
Von: James E. King III
Gesendet: 08.01.2019 16:33
An: dev@thrift.apache.org
Betreff: Branch history fixups

Our release branching strategy has left a number of loose ends.
Specifically, none of the release branches except for 0.12.0 have been
merged back into master.  Based on the way past releases were done, we
would branch off master then make a number of versioning changes which were
never intended to be merged back.  Without merging back, this leaves the
possibility that one could strand an important code change in a release
branch. It also leaves master with incomplete history.  In this type of
merge one does a "git merge --strategy-option=ours origin/<branch>" and
drops any collisions against master.

I'm going to start doing this for our release branches, ensuring the
resulting differences are negligible.  This will ensure we haven't missed
anything along the way, and GibHub will understand that a merge has already
occurred, so when we get a random pull request to merge 0.9.3 into master
(seems to happen about twice a year), there will be nothing to do.

- Jim