cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Date Fri, 20 Sep 2013 14:11:33 GMT
Yeah, but not sure how best to do so.

Do we have a way to mark plugins as deprecated?  Crazy idea: upload a
nearly empty version under the old plugin name that <depends> on the new
one, and add a <deprecated> type tag to plugin.xml spec?

-Michal


On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <michael@michaelbrooks.ca>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.
>
>
> 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