<html><head></head><body>Agreed. IMHO it's mainly a matter of communicating to users.<br>
All the best.<br><br><div class="gmail_quote">Il 7 marzo 2016 09:39:37 CET, Victor Olaya <volayaf@gmail.com> ha scritto:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">I would say that the "agrresive" approach (introducing API breaks<br />without waiting for next version) is a better option. Changes are<br />small and will be easy to adapt to (in most cases, it will happen that<br />an algorithm that changes is not used in any model, or just by a<br />handful of users). So the improvement-vs-annoyment ratio is high...<br /><br />My 2 cents<br /><br />2016-03-07 9:13 GMT+01:00 Alexander Bruy <alexander.bruy@gmail.com>:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hi all,<br /><br /> Processing, became an important part of QGIS. More and more users use it<br /> and rely on it, especially when they developed their own models and scripts.<br /> So we should keep Processing algorithms as stable as possible and don't<br /> change their descriptions.<br /><br /> On other hand there are many bugreports and feature requests which require<br /> changing
algorithms description to be fixed/impelemented. This can be considired<br /> as "API" break, as scripts and models which use affected algorithms<br /> and were developed before such changes will not work. For example,<br /> there were many<br /> PR about fixing GRASS and SAGA algs, which change their descriptions. Time<br /> from time we also fix bugs in native QGIS algs and also need to change<br /> algorithm description, e.g. by replacing one parameter type with another or<br /> adding new parameter.<br /><br /> I see only two solutions:<br /> 1. Postpone such changes for next major QGIS release when API break is<br /> allowed. In this case all existing scripts/models will work. But we<br /> should live<br /> with bugs and without some features, even if fix already available and keep the<br /> code of this fixes in sync with master until next major release.<br /> 2. Allow "API" breaks in Processing. In this case we create additional pressure<br /> on the authors of 3rd party
models/scripts and force them to follow Processing<br /> changes and update their code accordingly.<br /><br /> What do you think, which approach we should choose?<br /><br /> --<br /> Alexander Bruy<br /><hr /><br /> Qgis-developer mailing list<br /> Qgis-developer@lists.osgeo.org<br /> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /></blockquote><hr /><br />Qgis-developer mailing list<br />Qgis-developer@lists.osgeo.org<br />List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre></blockquote></div><br>
-- <br>
Paolo Cavallini<br>
<a href="http://www.faunalia.eu">www.faunalia.eu</a></body></html>