[Qgis-developer] Processing algorithms and API breaks

[Bernhard Ströbl]

Hi,

I once improved an algorithm but rolled it back afterwards because of [1]
So I fear that users become frustrated easily if things break every now 
and then which has further disadvantages:
1) QGIS (processing) is perceived as being unreliable
2) there will be tickets to be coped with addressing these issues

Nevertheless I would vote in favor of the "aggressive approach" but this 
has to be clearly communicated.

Bernhard

[1] http://hub.qgis.org/issues/13502

Am 07.03.2016 um 09:39 schrieb Victor Olaya:
> 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
>



__________ Information from ESET Mail Security, version of virus signature database 13137 (20160307) __________

The message was checked by ESET Mail Security.
http://www.eset.com