<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi<div class=""><br class=""></div><div class="">Personally, while I like new features, I would really like to encourage you to find a way to maintain a stable environment for processing users. For users of single algorithms the issue is probably less noticeable (although event then small changes may mean updating documented workflows etc.). But for users with complex models it is a real pain if their models break from version of version of process. So finding some way to support ‘write once, work always’ for processing is I think really important if you want people to broadly adopt it for all the powerful things it can do. </div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class="">On 07 Mar 2016, at 12:34, Alexander Bruy <<a href="mailto:alexander.bruy@gmail.com" class="">alexander.bruy@gmail.com</a>> wrote:<br class=""><br class="">Hi Matthias,<br class=""><br class="">when new parameter added and it is possible to declare it as optional,<br class="">I definitely do this. But sometimes parameters also removed or replaced<br class="">with another (e.g. string with point, or several numbers with extent). In<br class="">such cases algorithm semantic changes.<br class=""><br class="">Regarding versioning. Victor and me already discussed this approach.<br class="">Seems this can help with 3rd party models/scripts. Maybe we will work<br class="">on this at hackfest.<br class=""><br class=""><br class="">2016-03-07 11:12 GMT+02:00 Matthias Kuhn <<a href="mailto:matthias@opengis.ch" class="">matthias@opengis.ch</a>>:<br class=""><blockquote type="cite" class="">Hi Alex,<br class=""><br class="">Thanks for raising this issue. I also think that the interface to the<br class="">processing algorithms should stay as stable as possible, but slowing<br class="">down development speed also does not sound very appealing.<br class=""><br class="">Isn't it often possible to add a new parameter as optional with a<br class="">default value that conforms to the previous behavior? If developers keep<br class="">an eye on keeping their changes compatible this way, that should already<br class="">help a lot.<br class=""><br class="">Another idea is that the algorithms are versioned, so that with<br class="">incompatible changes an old model can still use the old algorithm. I can<br class="">imagine that the maintenance overhead for this is a bit high. The<br class="">lightweight approach for this can be done ad-hoc when introducing an<br class="">algorithm with a new name and keeping the old one in place.<br class=""><br class="">Matthias<br class=""><br class="">On 03/07/2016 09:13 AM, Alexander Bruy wrote:<br class=""><blockquote type="cite" class="">Hi all,<br class=""><br class="">Processing, became an important part of QGIS. More and more users use it<br class="">and rely on it, especially when they developed their own models and scripts.<br class="">So we should keep Processing algorithms as stable as possible and don't<br class="">change their descriptions.<br class=""><br class="">On other hand there are many bugreports and feature requests which require<br class="">changing algorithms description to be fixed/impelemented. This can be considired<br class="">as "API" break, as scripts and models which use affected algorithms<br class="">and were developed before such changes will not work. For example,<br class="">there were many<br class="">PR about fixing GRASS and SAGA algs, which change their descriptions. Time<br class="">from time we also fix bugs in native QGIS algs and also need to change<br class="">algorithm description, e.g. by replacing one parameter type with another or<br class="">adding new parameter.<br class=""><br class="">I see only two solutions:<br class="">1. Postpone such changes for next major QGIS release when API break is<br class="">allowed. In this case all existing scripts/models will work. But we<br class="">should live<br class="">with bugs and without some features, even if fix already available and keep the<br class="">code of this fixes in sync with master until next major release.<br class="">2. Allow "API" breaks in Processing. In this case we create additional pressure<br class="">on the authors of 3rd party models/scripts and force them to follow Processing<br class="">changes and update their code accordingly.<br class=""><br class="">What do you think, which approach we should choose?<br class=""><br class=""></blockquote><br class="">--<br class="">Matthias Kuhn<br class=""><a href="http://opengis.ch" class="">OPENGIS.ch</a> - <a href="https://www.opengis.ch" class="">https://www.opengis.ch</a><br class="">Spatial • (Q)GIS • PostGIS • Open Source<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Qgis-developer mailing list<br class=""><a href="mailto:Qgis-developer@lists.osgeo.org" class="">Qgis-developer@lists.osgeo.org</a><br class="">List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class=""></blockquote><br class=""><br class=""><br class="">-- <br class="">Alexander Bruy<br class="">_______________________________________________<br class="">Qgis-developer mailing list<br class=""><a href="mailto:Qgis-developer@lists.osgeo.org" class="">Qgis-developer@lists.osgeo.org</a><br class="">List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class=""></blockquote><br class=""><div class=""><span>—</span><br class=""><span><br class=""></span><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline"><span><img height="66" width="160" apple-inline="yes" id="4AE2F280-8077-4A4A-BCFA-F79E7FD75C8C" apple-width="yes" apple-height="yes" src="cid:62C890D4-3964-4609-BDE6-7536D5FBDD70" class=""></span><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class=""><br class="Apple-interchange-newline"><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class="">Tim Sutton</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: center;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="text-align: center;" class="">Visit <a href="http://kartoza.com" class="">http://kartoza.com</a> to find out about open source:</div><div style="text-align: center;" class=""><br class=""></div><div class=""><div style="text-align: center;" class="">* Desktop GIS programming services</div><div style="text-align: center;" class="">* Geospatial web development</div><div style="text-align: center;" class="">* GIS Training</div><div style="text-align: center;" class="">* Consulting Services</div><div style="text-align: center;" class=""><br class=""></div><div class=""><div style="text-align: center;" class="">Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net" class="">freenode.net</a></div><div style="text-align: center;" class="">Tim is a member of the QGIS Project Steering Committee</div><div style="text-align: center;" class=""><br class=""></div><div style="text-align: center;" class="">Kartoza is a merger between Linfiniti and Afrispatial</div></div></div></div>
</span></div><br class=""></div></body></html>