cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Date Fri, 20 Sep 2013 13:53:11 GMT
>
> We don't upgrade plugins as part of platform upgrade anyway, do we?  Still,
> its a good point that we may want to map these to newer versions.


Good point.

Regardless, we want to ease the upgrade path of these core plugins. It'll
just annoy users if we change the plugin IDs are hide these changes away in
our documentation.

Michael


On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mmocny@chromium.org> wrote:

> We don't upgrade plugins as part of platform upgrade anyway, do we?  Still,
> its a good point that we may want to map these to newer versions.
>
> One option could be to leave the old names registered in the plugin
> registry for a while, and mark deprecated somehow (and perhaps not make
> them visible from website?), but I think Andrew mentioned that installing a
> plugin from registry using one canonical name and having its plugin.xml
> specify a different canonical name meant our tools broke (fail to
> uninstall?).  Perhaps we should just fix that.
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > I prefer the shortened plugin IDs as well.
> >
> > Will we want each platform's upgrade script aware of these names in order
> > to ease the upgrade path from 3.0.0-3.1.0?
> >
> >
> > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Anis and I discussed a bit on
> > > https://issues.apache.org/jira/browse/CB-4493
> > >
> > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > >
> > > Wanted to see if anyone could think of what adverse effects this might
> > have
> > > before going through with it.
> > >
> > > Only thing I can think of is that I'd need to update the <dependency>
> > tags
> > > of all plugins (mobile spec and our own). The result of not updating
> them
> > > isn't horrible since the dependencies still install via URL.
> > >
> > > On a related note - we need remove the url= parameter from the
> > <dependency>
> > > so that it looks to the registry.
> > >
> > > Once we discuss / take one of these paths, I'd like to do a plugins
> > release
> > > so that we can test this flow with RC1.
> > >
> >
>

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