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