[Qgis-developer] Processing algorithms and API breaks

[Paolo Cavallini]

Hi Tim, Nyall,
while in principle I agree, I think this would be rather pointless in the current situation.
Many algs break often anyway because of changes in the backends. My suggestion:
" first put in place a complete set of tests
* only after that implement a versioning system
* provide clear instructions, possibly also tools, to help upgrading models to new versions (only power users actually build models).
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.
All the best.

Il 7 marzo 2016 22:37:39 CET, Nyall Dawson <nyall.dawson at gmail.com> ha scritto:
>On 7 March 2016 at 19:13, Alexander Bruy <alexander.bruy at gmail.com>
>wrote:
>
>> 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.
>
>I honestly think 1 is the only valid approach here.
>
>I'll preface this opinion by saying that I HATE frozen API with a
>passion. It makes development harder, slower and more expensive, and
>prevents new features landing and bugs from being fixed [1]. With my
>totally selfish developer hat on I'd love nothing more than for us to
>adopt a non-frozen, do-whatever-the-heck-you-want API and with no care
>for compatibility with old projects ;)
>
>BUT
>
>The decision has been made for the project that QGIS has a frozen API
>between major releases, and now that processing is part of the core
>QGIS install it also needs to abide by that rule! Yes, it's a freaking
>horrible PITA, but the alternative (breaking user's scripts and
>models) is far worse for the project. And with my non-developer, QGIS
>user hat on I would hate for scripts and models which I've invested
>time into creating to get broken between releases.
>
>I'd suggest following the same approach as is taken by the c++ code:
>make a versioned copy of the algorithm so that existing scripts/models
>can still use the old version BUT it's not exposed anywhere in the GUI
>and new models will transparently just use the new version. That's
>what we've done for labelling (heck... even the old label engine is
>STILL in QGIS on that extremely rare case that someone opens a pre 2.0
>project!), symbology, various composer items, etc. It results in
>duplicate code and fills the codebase with a lot of deprecated cruft,
>but that's the price of a frozen API :)
>
>Just my 2c! ;)
>Nyall
>
>1. see https://github.com/qgis/qgis3.0_api/issues for a list of stuff
>we CAN'T implement/fix until API is unfrozen
>_______________________________________________
>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/20160308/aabef974/attachment.html>