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 <[email protected]> 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 <[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
> >>>
> >>
>
>
