One possible solution to this is to encourage cherry-picking in the other direction, during the period between the RC release and the x.x.0 release.
So, until 2.6.0 is released, if you are doing 2.6. work, then you can work on the 2.6.x branch, fix things there, and then cherry-pick those fixes back to master. Once 2.6.0 is released, then I expect that everyone would be working on 2.7 features, working on master, and any cherry-picks would go the other way (from master to 2.6.x) It really doesn't matter to git which way the picks go; and the important thing to us is that they end up on both branches in the end. If it makes more sense for your workflow to be working on 2.6.x (to get 2.6.0 out the door), then do that. If you're working on new features for 2.7, then work on master. But, as Braden says, just don't merge between the two. Once branched, they should stay branched. Ian On Fri, Apr 5, 2013 at 12:06 PM, Braden Shepherdson <bra...@chromium.org>wrote: > Cherry-picking is the right solution for release branches. The problem is > that people are merging between 2.6.x and master. > > Never do it. In either direction. It is always the wrong thing. > > Commit to master, cherry-pick to 2.6.x if it's fixing something critical > for the release. > > > On Fri, Apr 5, 2013 at 12:04 PM, Joe Bowser <bows...@gmail.com> wrote: > > > Yeah, I realized this when I tagged 2.6.x for Android that the tests > > that were failing were features that didn't exist yet. It might make > > sense to revert mobile-spec. > > > > In hindsight, I think our reliance on cherry-picking is weird, and we > > should just work on 2.6 until release, THEN cherry-pick for any minors > > that we have to make after that. > > > > On Fri, Apr 5, 2013 at 8:57 AM, Ian Clelland <iclell...@google.com> > wrote: > > > It looks like a number of commits intended for 2.7.0 were merged back > > into > > > the 2.6.x branch > > > > > > My commits: > > > dbf631c: [CB-2305] Add spec tests for InAppBrowser.insertCSS and > > > InAppBrowser.executeScript APIs > > > 46e478f: [CB-2226] Add spec test for FileTransfer.abort error callback > > > da89eaa: [CB-1517] [CB-1518] Add spec test for gzip-encoded resources > > > 2003ff7: [CB-1517] Add an assertion that progress.total < > progress.loaded > > > > > > were all committed to master after the 2.6.x branch was split, but then > > > master was merged back into 2.6.x (acd1b96, Apr 2) > > > > > > There may be other commits in there that were merged accidentally; I > > > haven't looked at all of them yet. I think that any commits from master > > > which *should* be in 2.6.x should have been cherry-picked, rather than > > > merging master. > > > > > > From the iOS thread, I see that da89eaa was reverted, but the rest of > > them > > > are still on the 2.6 branch. > > > > > > It's probably too late to just rewind the 2.6.x branch back to f6cbe2e > > > (rewriting public history and all that,) but should we revert the other > > > commits before we tag 2.6.0? > > > > > > Ian > > >
