Let's revert, not rollback. I'm sure we expected some teething pains adjusting to the new scheme.
On Friday, April 5, 2013, Ian Clelland 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 >