cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@google.com>
Subject Re: Mobile-Spec contains Cordova 2.7 tests
Date Fri, 05 Apr 2013 16:33:24 GMT
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 <braden@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 <bowserj@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 <iclelland@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message