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 <[email protected]> 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 <[email protected]> > 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 < > [email protected] > > >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 <[email protected]> > > 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 < > > > [email protected] > > > > >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 < > > [email protected] > > > > > >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. > > > > > > > > > > > > > > > > > > > > >
