commitToBranch('master');
if (inReleaseMode && commitFixesRegression) {
cherryPickCommit('CB-xxxx').from('master').into('releaseBranch');
}
-James Jong
On Mar 28, 2013, at 11:07 AM, Michal Mocny <[email protected]> wrote:
> We create branch when we decide to cut a release. This is the cut off for
> features.
>
> At that point, ALL commits continue on master, however, any regression
> fixes we want are cherry picked into release branches.
>
> This way, there is no confusion for contributors. All work is always done
> on master, and any branch can try to cherry pick any regression fix.
>
> Contributors don't necessarily need to care about how we do releases, and
> release maintainers don't need to dictate work on master.
>
> If we all work this way, there is no need for any merges.
>
> -Michal
>
> p.s. Should be obvious, but, cherry picking becomes a lot easier if commits
> to master are squashed as much as possible into self contained units. Ie,
> dont add fly-by changes/features into your regression fixes, and don't
> split your fixes into 5 incomplete patches. This can't always be avoided
> completely, but I cringe when I see [commit 1/16] emails.
>
>
> On Thu, Mar 28, 2013 at 10:50 AM, Joe Bowser <[email protected]> wrote:
>
>> Why aren't we merging them again? I don't remember the reasoning for that.
>>
>> I'll cherry pick the changes into master today, although I don't remember
>> us deciding on not merging when we do a release. This seems kind-of weird.
>> On Mar 28, 2013 6:04 AM, "Braden Shepherdson" <[email protected]> wrote:
>>
>>> I think I saw a bunch of git commit messages go by that were committing
>>> things to 2.6.x.
>>>
>>> Remember that the intended flow is that things get committed to master
>> and
>>> then cherry-picked into 2.6.x if they're critical fixes.
>>>
>>> We WILL NOT ever merge master and 2.6.x in either direction, so commits
>>> that only exist in 2.6.x will be lost if they are not cherry-picked into
>>> master.
>>>
>>> Braden
>>>
>>
