Hi > On 06 Feb 2017, at 12:35 PM, Victor Olaya <[email protected]> wrote: > > > One thing I am concerned about is that we guarantee some stability in the > behavior of processing. While it is true that strictly speaking new > algorithms do not represent API extensions / additions, in some level I think > they do since anyone using Python + Processing will be vulnerable to future > behavioral changes / deletions from the set of tools shipped with processing. > If we want to get plugin writers to rely on Processing rather than > implementing geoprocessing etc. functionality themselves, they need to know > that a) the algorithms they need will be installed on their user's computers > and b) that those algorithms will behave in a consistent way across the major > release life cycle of QGIS. > > > I think we can have good control over that. Once the code is in the QGIS repo > and authors work on it there via PRs, we shouldnt allow them to modify > algorithm semantics or do any 'crazy' change. We have control over that. So > actually it is better to have it in core for that kind of integration, since > we, as QGIS project , will likely be more strict than a developer working on > his own repo, and take all this into account.
Yeah that makes sense .... Thanks Tim > — Tim Sutton Co-founder: Kartoza Project chair: QGIS.org Visit http://kartoza.com <http://kartoza.com/> to find out about open source: Desktop GIS programming services Geospatial web development GIS Training Consulting Services Skype: timlinux IRC: timlinux on #qgis at freenode.net Kartoza is a merger between Linfiniti and Afrispatial
_______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
