With the new SIP API, we should find the best way to publish plugins for various QGIS versions in one repository. It's no problem in small repositories, where all multiple versions may exist side by side, because the plugin installer (both: old and new) can filter the best availale version. But the new central repository contains hundrets plugin versions, so for performance reasons it only exposes the most recent version of each plugin in the xml. If QGIS version is explicitly pass in the url (e.g. http://blahblahblah.xml?qgis=1.9), the repository returns the most recent *compatible* version. Otherwise - just the most recent. The new installer includes current QGIS version to the URL, old one doesn't. So if there is an old plugin version for QGIS 1.x, and a newer for QGIS 2.0+ , Qgis 1.8 won't show it at all - because the repository will only return the latter, what will incompatible.
There is a few solutions I see: 0. Don't change anything, just say to plugin maintainers to make all existing plugins compatible with both API. IMHO unacceptable solution; it was possible for small API improvements during 1.x API, but forcing people to maintain completely old API in complex plugins can only discourage them from further maintaining. 1. Release an update for the the old plugin_installer, with the current version added to the url. Fast and easy, however I see some downsides: - Generally I'm not very keen to mess user's dicertory with core plugin updates unless it's really justified. - Either 1.8 packages will be updated too or it will require immediate plugin_manager upgrade right after installation. - Unless the plugin_manager is upgraded, many plugins dissapear. Looks like a nasty and surprising regression during using the stable 1.8. This is probably disqualifying. 2. Change the new repository policy: let it returns plugins for QGIS 1.8 when called without the ?qgis= url parameter. This means: the ?qgis= parameter is required, and the lack of it is a depreciated exception, only designed for QGIS 1.8. With this reservation it looks reasonable for me. Please note the new pyplugin_installer (it's a part of the manager working usually under the hood) adds this ?qgis=$CURRENT_VERSION parameter anyway. 3. Like 2, but return the full list of plugins when called without the parameter. Advantage: more clear than 2. Disadvantage: more server load and longer (maybe much longer?) repository fetching in QGIS 1.8 I vote for the solution 2. _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer