[Qgis-developer] Processing algorithms and API breaks
cavallini at faunalia.it
Mon Mar 7 22:53:12 PST 2016
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>
>> 1. Postpone such changes for next major QGIS release when API break
>> 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 . 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 ;)
>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! ;)
>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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer