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 18:28:06 GMT
When updating platforms, I think we re-install already-installed-plugins,
right?  Should make sure that that doesn't lead to annoying warning chain
and/or broken workspace.

Also, solution seems hacky.  What don't you like my crazy idea to change
old plugin to <depend> on new version? ;)

-Michal


On Fri, Sep 20, 2013 at 2:16 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> 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