cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Creating repos for core plugins
Date Mon, 04 Feb 2013 22:53:43 GMT
+1, I agree on the separate repositories.
I still contend that nothing should need to be 'built' and there should be
NO dependencies on the plugins from cordova-js, ( aside from device.js +
network.js which are both required pre device ready, and I think should
remain in the cordova-js repo )



On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> +1 for separate repositories. Should take a bit longer than normal to
> package a release but not too long especially if the repos are pulled from
> a local source (ie no network overhead).
> I'd be ok to ship a set of default plugins and give the ability for people
> to build their 'own' Cordova.
>
>
> On Mon, Feb 4, 2013 at 2:11 PM, Brian LeRoux <b@brian.io> wrote:
>
> > I'm in favor of discreet plugin repos. It shouldn't effect a release
> > if we automate install/remove and add to the Coho tool... though
> > perhaps this is a naive assumption.
> >
> > On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > > Thought it'd be worth having a discussion around whether we want a
> > separate
> > > repo for each core plugin or not.
> > >
> > > As far as I can see, we can either have all core plugins in one repo,
> or
> > > have each in it's own and call them:
> > > cordova-plugin-file
> > > cordova-plugin-network
> > > cordova-plugin-media
> > > etc...
> > >
> > > I think my preference would be to have them as their own repos so that
> it
> > > will be easier to add/remove lists of plugins to the "which ones are
> > core"
> > > list. It will also let us version them separately (if we want to do
> > this).
> > >
> > > The downside is that it may take longer to perform a release? Would we
> > even
> > > bundle the plugins with releases anyways though?
> >
>



-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message