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). >> >> >>
