cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: Committing to 2.6.x
Date Thu, 28 Mar 2013 15:07:21 GMT
We create branch when we decide to cut a release.  This is the cut off for

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.


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 <> 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" <> 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
> >

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