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 <mmo...@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 <mich...@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 <mmo...@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 < > > mich...@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 < > agri...@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. > > > > > > > > > > > > > > >
