re: COHO I cannot guarantee the output of windows/phone releases if they are tagged and updated via coho. I like the idea of having continuous integration, but this is not there yet. I would prefer for now to manually update and tag wp7+wp8+windows8 repos because I do not currently trust the magic in coho, and do not have time to go and understand all of the magic.
@purplecabbage risingj.com On Wed, Jul 10, 2013 at 3:36 PM, Steven Gill <stevengil...@gmail.com> wrote: > Plugin versioning is definitely something we need to discuss in detail. > > What happens if I make a change to the camera plugin. Do I immediately bump > the version? Probably not. But people who install it using plugman/cli > after the change will get the latest one on master with no obvious > difference to them. Version wise it is the same as before the change. This > feels wrong. > > We can now update plugins independently of our once a month release and get > those updates to our users instantly. I think we should update the version > of the plugins after every change. Similar to node-modules on npm. > > Coho is not just for packaging. I love the fact that I can clone and update > all of the repos in a few quick commands. Coho seems to have the ability to > do tagging, release packaging and signing, uploading releases to apache, > cloning all repos and soon generating release issues on jira. It will be > important to solve all of the issues people are having with coho and > document what you can do with it. > > > On Wed, Jul 10, 2013 at 3:15 PM, Joe Bowser <bows...@gmail.com> wrote: > > > I'm going to create a new thread about this, but what's the purpose of > > coho again? I thought it was just for packaging releases. > > > > On Wed, Jul 10, 2013 at 3:07 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > Our intern Jeffrey is actively working on adding a command to coho to > be > > > able to create release bugs (based off of cordova-labs). If he gets > done, > > > by Monday, then it'll be a cinch to create the issues. > > > > > > We could maybe start by discussing what we want to do with the plugin > > repos > > > for the release. > > > > > > Should they all have release branches? > > > Should they be versioned the same? e.g. 3.0.x, or should they start out > > at > > > 1.0.x? > > > Are we including a .zip of all of them in our apache distribution .zip? > > > > > > > > > Here's a stab at it from me: > > > > > > - Always include all core plugins in the apache release .zip > > > - If a plugin has not changed since the previous release, then just put > > in > > > the previous release of the .zip. > > > - E.g. for 3.1.0, if plugin-console has no changes, then just > package > > > version 3.0.0 of the plugin in the release > > > - Create release branches for the plugin repos only if there has been a > > > commit since the previous release > > > - If there were no commits, then there cannot be any regressions, so > > no > > > need for a release branch. > > > - I think they should be versioned the same to help us figure out when > > the > > > last change was. > > > - This could mean that if plugin-console goes three months without a > > > change, it will go from 3.0.0 straight to 3.3.0 > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 10, 2013 at 5:50 PM, Filip Maj <f...@adobe.com> wrote: > > > > > >> Yeah.. Maybe we should create the issues for the rc soon? > > >> > > >> On 7/10/13 1:57 PM, "Andrew Grieve" <agri...@chromium.org> wrote: > > >> > > >> >I would put that at next week unless someone has cycles to get on it > > this > > >> >week. > > >> > > > >> > > > >> >On Wed, Jul 10, 2013 at 4:24 PM, Marcel Kinard <cmarc...@gmail.com> > > >> wrote: > > >> > > > >> >> When will the Upgrade Guides (2.9 -> 3.0) be written? That content > is > > >> >> currently not in cordova-docs. > > >> > > >> > > >