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.orgwrote:
Anis and I discussed a bit on
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
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
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: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
On Fri Sep 20 10:11 AM, Michal Mocny 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?
It sort
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
