Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CABiQX1UC+U9EkzS8U1mcnZAeNKfLz6iVe+ixW72EUXw=5EhBqg@mail.gmail.com>
References: 
 <CADVgkyMZmhcc8RbLNyNXi3cJ9iM=h9ScvU2ZnET3X4q9L95V1w@mail.gmail.com>
	<CD19BDD4.158A2%fil@adobe.com>
	<CABiQX1WbsVx9W5DaxN-77_x5RAOHSodnsiRPxURzCgQLqMjXCQ@mail.gmail.com>
	<CADVgkyMtbYhhpjLkEHv=ru3LiWp0TrrZ1HnbR9cKnzr4o+1aLA@mail.gmail.com>
	<CABiQX1UC+U9EkzS8U1mcnZAeNKfLz6iVe+ixW72EUXw=5EhBqg@mail.gmail.com>
Date: Mon, 14 Jan 2013 14:34:19 -0800
Message-ID: 
 <CADVgkyND4nLsY4m9iQsp8xz_A2xVK4Gc+3232WZVeHtH==gEQQ@mail.gmail.com>
Subject: Re: too long to package a release?
From: Brian LeRoux <b@brian.io>
To: dev@cordova.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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