Coho started as just a tool to package, but has grown into a tool that: a) helps work with multiple repos b) documents our release process in working code.
re windows tagging - As of the last release bug template, we're tagging each branch individually either via coho or not, so no issue there. It won't be tagged by coho unless someone does it explicitly. I think we can still use it to create the windows release branches, since if it messes up we can just fix what it missed (but all it does is update VERSION and cordova.js). As for plugins, I've only used CLI by pointing at directories so far, but I was under the impression that if you give it a URL, you have to give it a repo + subdirectory + hash/tag combination. If it's currently just installing from master, I think that's a bad default and should instead go by a tag (npm goes by the "stable" tag by default I believe). So... we will need an explicit action for commits to a plugin to be picked up by plugman. How about if a plugin has a commit that is urgent, it gets a point release right away. Otherwise, it waits for the next Cordova release cycle. On Wed, Jul 10, 2013 at 6:47 PM, Jesse <purplecabb...@gmail.com> wrote: > 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. > > > >> > > > >> > > > > > >
