Re: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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 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.
Re: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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.cawrote: 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.
Re: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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.
Re: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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 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.
Re: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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.
RE: Change plugin IDs from org.cordova.core.FOO - org.cordova.FOO
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 of brings us back to required vs. non-required dependency: https://issues.apache.org/jira/browse/CB-4735 I think you'd end up with: plugin list org.cordova.core.FOO org.cordova.FOO My pref would be to 'break stuff' then have a placeholder for deprecated plugin ids. All we really want here is way to resolve org.cordova.core.FOO -- org.cordova.FOO for backwards compatibility. Harmony proposal calls this step resolve(),lots of similarity : http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders Having a way to register aliases or alternative ids/names could be useful in some sort of 'resolve' step.
