cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Jasmine Tests failing with the most recent multipart changes
Date Tue, 26 Feb 2013 17:43:30 GMT
Yep, I agree with you Andrew. Lets ride out the current next/master Git
workflow for the 2.5.0 release. Afterwards, we can kick up a
retrospective thread
to discuss the pros / cons / improvements.

On Monday, February 25, 2013, Andrew Grieve wrote:

> Do the changes you'd like to see cherry-picked fix regressions? If not,
> then I'd say just leave them broken in 2.5.
>
> I think what'd you'd do then is cherry-pick into next, and then immediately
> merge next into master. The merge in this case should have a conflict
> because of the two identical changes, but it should be able to auto-resolve
> them.
>
> So far, I've been finding this workflow much better for having forward
> progress. Since we created the next branch, we've have 17
> non-regression-fixing commits to cordova-ios. In our old flow, this number
> would be 0.
>
> I am also finding that having to figure out if I want to commit to next vs
> master *before* I make a change to be taxing though. The reason we're doing
> it this way around is so that we can use the same release branch "next" for
> the next release as well. If we used named branched (e.g. "next2.5.0") then
> we could commit to master and cherry-pick after-the-fact the changes we
> want in the release branch.
>
> Let's maybe discuss our options here after this release is over with.
>
>
>
> On Mon, Feb 25, 2013 at 3:10 PM, Joe Bowser <bowserj@gmail.com<javascript:;>>
> wrote:
>
> > I haven't cherry-picked anything into next yet.  I've kept working on
> > master and I've been ignoring next.  However, there's some things in
> > master that I would like to see in the next release.  How do we do
> > that without cherry-picking? Or do we just keep things broken in 2.5
> > and just shrug our shoulders and say whoops?
> >
> > Again, I think this work-flow is terrible, and I would like to go back
> > to what we used to do if cherry-picking really breaks things this bad.
> >
> > On Mon, Feb 25, 2013 at 12:01 PM, Andrew Grieve <agrieve@chromium.org<javascript:;>
> >
> > wrote:
> > > Joe - do you mean you're committing to master and cherry-picking into
> > next?
> > >
> > > I think this would result in two identical-but-different changes
> > appearing
> > > in the two branches, whereas checking into next and merging into master
> > > ends up with the same change appearing in both branches. The result of
> > this
> > > (I think) is that cherry-picking will make history a bit more
> confusing,
> > > and increase the risk of future merges having conflicts.
> > >
> > >
> > > On Mon, Feb 25, 2013 at 1:52 PM, Joe Bowser <bowserj@gmail.com<javascript:;>>
> wrote:
> > >
> > >> That's assuming that we're fixing for release.  I've been doing all
> > >> work in master at this point. I think we're fine doing both
> > >> cherrypicks and merging, but I think that's what makes this process
> > >> complicated.
> > >>
> > >> On Mon, Feb 25, 2013 at 10:42 AM, Filip Maj <fil@adobe.com<javascript:;>>
> wrote:
> > >> >
> > >> >>Also, on a side note, for the release, if there's commits in master
> > >> >>that we want in this release, do we do a cherry pick into next?
> > >> >
> > >> > Yes. I see it the opposite way (I commit into next and merge into
> > >> master).
> > >> >
> > >>
> >
>

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