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