<div dir="ltr">Hey Borys,<div><br></div><div>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.</div>

<div><br></div><div style>- Nathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 9:57 PM, Borys Jurgiel <span dir="ltr"><<a href="mailto:lists@borysjurgiel.pl" target="_blank">lists@borysjurgiel.pl</a>></span> wrote:<br>

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