On Fri, Sep 20, 2013 at 2:28 PM, Michal Mocny <mmo...@chromium.org> wrote:
> 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. > Braden just added the "platform update" command two days ago, and all it does is call the platform's "update" script. It doesn't touch your plugins. Probably we should do some checks to ensure your plugins are compatible, and maybe suggest updating plugins, but we don't have any of that right now. > > Also, solution seems hacky. What don't you like my crazy idea to change > old plugin to <depend> on new version? ;) > Might be a bit confusing to "plugin ls" and see two copies of each plugin, where one of them you can't uninstall because it's depended on. > > -Michal > > > On Fri, Sep 20, 2013 at 2:16 PM, Andrew Grieve <agri...@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 <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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
