[Qgis-developer] Processing algorithms and API breaks

[Paolo Cavallini]

Agreed. IMHO it's mainly a matter of communicating to users.
All the best.

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

-- 
Paolo Cavallini
www.faunalia.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160307/95c15be9/attachment.html>