cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jong <wjamesj...@gmail.com>
Subject Re: Committing to 2.6.x
Date Thu, 28 Mar 2013 16:54:30 GMT
commitToBranch('master');
if (inReleaseMode && commitFixesRegression) {
    cherryPickCommit('CB-xxxx').from('master').into('releaseBranch');
}

-James Jong

On Mar 28, 2013, at 11:07 AM, Michal Mocny <mmocny@chromium.org> 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 <bowserj@gmail.com> 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" <braden@chromium.org> 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
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message