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
