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

Reply via email to