Sounds good. Let me introduce yet another headache - config.xml changes. Case in point, the change of the root element from "cordova" to "widget". I filed an issue here: https://issues.apache.org/jira/browse/CB-2727
Copied below: ------------ plugin.xml: https://github.com/shazron/ZipUtil/blob/a0fd1b26964bbf55e061fa664f82598fae57a0ea/plugin.xml#L19-L29 Because of the config.xml root element change from *cordova* to *widget* beginning in 2.5.0, plugins that target an older version cannot be installed effectively in config.xml. Uncommenting the block specified for 2.3.0/2.4.0 (see link above) would work if you are targeting those specific versions, but if your plugin supports 2.3.0 and above, having both *config-file* tags won't work. We need a solution for this scenario. ---------- On Tue, Mar 19, 2013 at 7:59 AM, Anis KADRI <anis.ka...@gmail.com> wrote: > Hey all, > > Plugins need to be versioned to be backward compatible with previous > versions of Cordova. I had a discussion with the PhoneGap:Build team > yesterday and they need to be backward compatible. Ally Ogilvie also > mentioned in separate thread that game developers would also need something > like this. > > We have already broken the plugin interface a number of times and we know > that a plugin implementation won't work across all versions of Cordova. > The plugin spec already supports an <engine> tag to specify which versions > of cordova it supports. However, It's expensive to clone down the > repository just to check if the plugin works or not. > > I believe we should store some sort of mapping on our discovery server. > Such as: > > { > cordova_version: plugin_versions > } > > That way when plugman tries to install a plugin it knows ahead of time > (before cloning the repository) if there is a version of the plugin that > works with the user's version of cordova. > > This will probably be less needed after 3.0 when the plugin interface is > stable enough. > > Thoughts ? > > -a >
