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