
<html><head></head><body>Hi Tim, Nyall,<br>

while in principle I agree, I think this would be rather pointless in the current situation.<br>

Many algs break often anyway because of changes in the backends. My suggestion:<br>

" first put in place a complete set of tests<br>

* only after that implement a versioning system<br>

* provide clear instructions, possibly also tools, to help upgrading models to new versions (only power users actually build models).<br>

IMHO a current major stumbling block for users is the lack of documentation for hundreds of algs, many of them quite obscure. Better address this first.<br>

All the best.<br><br><div class="gmail_quote">Il 7 marzo 2016 22:37:39 CET, Nyall Dawson <nyall.dawson@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">On 7 March 2016 at 19:13, Alexander Bruy <alexander.bruy@gmail.com> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> 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 /></blockquote><br />I honestly think 1 is the only valid approach here.<br /><br />I'll preface this opinion by saying that I HATE frozen API with a<br />passion. It makes development harder, slower and more expensive, and<br />prevents new features landing and bugs from being fixed [1]. With my<br />totally selfish developer hat on I'd love nothing more than for us to<br />adopt a non-frozen, do-whatever-the-heck-you-want API and with no

care<br />for compatibility with old projects ;)<br /><br />BUT<br /><br />The decision has been made for the project that QGIS has a frozen API<br />between major releases, and now that processing is part of the core<br />QGIS install it also needs to abide by that rule! Yes, it's a freaking<br />horrible PITA, but the alternative (breaking user's scripts and<br />models) is far worse for the project. And with my non-developer, QGIS<br />user hat on I would hate for scripts and models which I've invested<br />time into creating to get broken between releases.<br /><br />I'd suggest following the same approach as is taken by the c++ code:<br />make a versioned copy of the algorithm so that existing scripts/models<br />can still use the old version BUT it's not exposed anywhere in the GUI<br />and new models will transparently just use the new version. That's<br />what we've done for labelling (heck... even the old label engine is<br />STILL in QGIS on that extremely rare case that

someone opens a pre 2.0<br />project!), symbology, various composer items, etc. It results in<br />duplicate code and fills the codebase with a lot of deprecated cruft,<br />but that's the price of a frozen API :)<br /><br />Just my 2c! ;)<br />Nyall<br /><br />1. see <a href="https://github.com/qgis/qgis3.0_api/issues">https://github.com/qgis/qgis3.0_api/issues</a> for a list of stuff<br />we CAN'T implement/fix until API is unfrozen<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></pre></blockquote></div><br>

-- <br>

Paolo Cavallini<br>

<a href="http://www.faunalia.eu">www.faunalia.eu</a></body></html>