cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: too long to package a release?
Date Mon, 14 Jan 2013 22:48:30 GMT
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 <agrieve@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 <agrieve@chromium.org>
> >> wrote:
> >> > On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj <fil@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).
> >>
>

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