[Qgis-developer] Plugins for 1.8 and 2.0 in one repository

[Matthias Kuhn]

Hi Borys, I just had a look at the plugin manager. Big thumbs up, this 
is good stuff!!

To your question: version 2 sounds reasonable to me as well. We can 
easily control the future parameters and append the qgis version always.

Am I correct, that in the future, there is no (easy) way of installing 
an older version of a plugin?
If yes, I'm not really a fan. If the plugin maintainer releases a buggy 
version, there is no way to revert to an old working version until the 
maintainer releases a bugfixed version.

All in all, what are we talking about in terms of size? With a 
compression enabled HTTP connection, I don't expect the plugin xml to 
be too large to pass through any internet connection in a timely manner.
Also, this request can easily happen asynchronously, so we don't even 
have to interrupt the UI.

Best
Matthias

On Don 06 Jun 2013 13:57:28 CEST, Borys Jurgiel wrote:
> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer