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:05:06 GMT
Mike: open tickets against the platforms for this. I think its a great idea.

On Mon, Jan 14, 2013 at 2:47 PM, Michael Brooks
<michael@michaelbrooks.ca> wrote:
>>
>> 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?
>
>
> Now's my chance to loop back to the other discussion point of this thread.
> Building a release should be automated and I'd like to propose that we
> introduce another script:
>
>     ./bin/dist <version>
>
> I would go as far as I require any platform wanting to be included in a
> release
> to include the distribution script. For what it's worth, BlackBerry has had
> this
> script for over two years.
>
> Ideally, we should also standardize how to install any dev environment
> dependencies. In my mind, it would make sense to require a script similar to
> the UNIX ./configure to install and/or verify any developer dependencies.
>
> To do an Apache Cordova release, we following steps similar to:
>
>     Each platform
>         Checkout stable git branch
>         $ ./configure
>         $ ./bin/dist <version>
>      Zip everything up
>
> On Mon, Jan 14, 2013 at 2: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