I think cherry-picking the same as a rebase+merge? If branches are:
feature --> dev --> unstable --> stable Then I don't think we'd ever do dev->stable. Who should do it? I think for dev-> unstable, whoever wants to start a release can just do it (maybe we could rotate the responsibility of release person?) For unstable->stable, I think owners from each platform should do this (in the same spirit as is done right now), since this is essentially the same as the tagging step. When should we do it? For dev->unstable, maybe 2 weeks before our planned release date? This gives 2 weeks of testing / release candidates before tagging a final. Should RCs be tagged on unstable or stable? I think both "Next" or "Staging" make more sense than "unstable". On Mon, Jan 14, 2013 at 6:10 PM, Brian LeRoux <b...@brian.io> wrote: > Oh, yes, that is true. I was assuming (naively) that this wouldn't be > a likely case if we were diligent about rebasing before commits > landing. > > So, the real trick here is, a workflow of: > > feature --> dev --> unstable --> stable > > When, and more importantly who, does the Canonical brach to Canonical > branch merges? (Eg. dev --> stable ) > > > > On Mon, Jan 14, 2013 at 2:48 PM, Braden Shepherdson <bra...@chromium.org> > wrote: > > Aside from the extra overhead and coordination, which I think are a major > > problem, this is a recipe for disaster with merge commits. This doesn't > > require manual conflict resolution to be a problem. Just that, if feature > > branches A and B are merged into dev/unstable and a merge commit is > > created, they and their merge commit now have to be moved to > unstable/next > > as a group. These features may be from different developers, etc. etc. > > > > > > On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux <b...@brian.io> wrote: > > > >> I think its basically the same except cherry picking not necessary. > >> (But I've been known to be very wrong so take that with a grain of > >> salt!) > >> > >> You work on a Feature branch. It gets rolled into Dev as needed so > >> others can merge / collaborate on said feature. When it feels right > >> instead of merging a large set of potentially breaking commits to > >> Unstable the dev working on said feature just merges that feature. > >> This would require more responsibility for the committer to keep track > >> of their feature branches which I could see as being more overhead. > >> > >> My ideal here is to get to a point where there is something, whatever > >> it is, that we want to denote as a release. That something should not > >> require a whole bunch of coordination. There should be a working > >> branch, whatever we call it, ready for a tag and nothing else on any > >> arbitrary date to be considered a release. Does that make sense? > >> > >> > >> > >> On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve <agri...@chromium.org> > >> wrote: > >> > Could you elaborate on what the workflow would be if we merged only > from > >> > Feature branches? > >> > > >> > On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux <b...@brian.io> wrote: > >> > > >> >> So, what if Canonical branches only received merges from Feature > >> >> branches...? > >> >> > >> >> On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve <agri...@chromium.org > > > >> >> wrote: > >> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <f...@adobe.com> wrote: > >> >> > > >> >> >> > >> >> >> >But do Canonical branches merge into each other? I'm thinking no. > >> >> >> > >> >> >> My understanding: > >> >> >> > >> >> >> - work goes into feature branches > >> >> >> - when contributor(s) deem feature is ready, merge into Unstable, > >> which > >> >> >> then gets vetted (test!!!!!) > >> >> >> - at some point unstable merges into Next > >> >> >> - when tagging, we merge Next into Stable and tag > >> >> >> > >> >> > > >> >> > That's my understanding as well. > >> >> > > >> >> > The "At some point" part would be when we say "hey, let's start > >> working > >> >> on > >> >> > cutting a release", which should align with the wiki's > >> >> > RoadMap<http://wiki.apache.org/cordova/RoadmapProjects> (which > >> >> > targeted 2.3 for November, whoops!). > >> >> > > >> >> > > >> >> >> > >> >> >> Would be different for bug fixes or other maintenance-type commits > >> too, > >> >> >> ya? Those would be directly into Next. > >> >> >> > >> >> > It might cause headaches to commit bug-fixes into Next when it > comes > >> time > >> >> > to merge Unstable -> Next. > >> >> > > >> >> > > >> >> >> > >> >> >> Finally, what about hot fixes / patch releases? Branch off the > tag in > >> >> >> Stable and put hot patch work into there? > >> >> >> > >> >> > Agree. I think the flow here should be to commit change to Unstable > >> and > >> >> > then cherry-pick it into a branch off the tag (when feasible). > >> >> > >> >
