cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: too long to package a release?
Date Mon, 14 Jan 2013 23:10:07 GMT
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 <braden@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 <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
View raw message