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