cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Committing to 2.6.x
Date Thu, 28 Mar 2013 18:06:09 GMT
Thank you, good pseudocode.

I might add:

addEventListener('merge', function(from, to) {
   if ((from == 'master' && to == '2.6.x') ||
       (from == '2.6.x' && to == 'master')) {
     throw new Error("No! Bad kitty.");
   }
});


On Thu, Mar 28, 2013 at 12:54 PM, James Jong <wjamesjong@gmail.com> wrote:

> 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