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 <bows...@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 > > <agri...@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 > > > <bows...@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 > > >> <f...@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). > > >> > > > >> > > >
