Ok, then we can cherry pick the commits that improve SAGA support, to backport them to the 2.8 branch. Makes sense
2015-12-24 8:06 GMT+01:00 Paolo Cavallini <[email protected]>: > Il 24/12/2015 07:46, Victor Olaya ha scritto: >> I think that changes in Processing to support newer SAGA versions have >> not been backported to the 2.8.x series, which explains that. >> >> However, with SAGA being the less predictable software ever having >> tons of API breaks in each version...I dont think our LTR should move >> the supported SAGA version. If 1.8 had support for SAGA 2.1, it should >> stick to that for all 2.8.x, and actually the installers and bundles >> should not advance the version and ship that same version of SAGA >> always. And if not using a bundled version, the user should install >> the supported version of SAGA, not a more recent one, since that will >> probably compromise the stability. > > Hi Victor, > thanks for the response. Unfortunately, this holds true only for distros > where we have complete control over the stack (only Win, I believe). On > Debian, as in my case, packages get updated all the time, so we really > have no choice. I acknowledge the issues with saga changes; on the other > hand, supporting newer versions on more context will help us spotting > issues and fixing them earlier. > Of course, the alternative is to fork saga and keep and internal stable > version. I noticed, however, that currently there seems to be more > activity than in the past, so forking will be bad: > http://sourceforge.net/p/saga-gis/code-0/commit_browser > All the best. > -- > Paolo Cavallini - www.faunalia.eu > QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
