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