cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Date Fri, 20 Sep 2013 18:16:25 GMT
The current way to upgrade your plugin is:
cordova plugin rm old.plugin.id
cordova plugin add new.plugin.id

Maybe we could just add a check in plugman that when it sees "plugin add
org.cordova.core", we print a message telling them to omit ".core"


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

> 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