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

[Nathan Woodrow]

Hey Borys,

I think option 2 is the best.  Anything we can do server side is the best
option to reduce any hider on the users.  As long as this is noted with the
plugin repo API then I see no issue.

- Nathan


On Thu, Jun 6, 2013 at 9:57 PM, Borys Jurgiel <lists at borysjurgiel.pl> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130606/c51a57ed/attachment.html>