On 8/29/19 10:43 AM, Sandro Santilli wrote:
recommendation being that users who need to open a 1.x project first
load and resave it in 2.18.
Will try that. Then I guess I'll have to update DBManager templates
in all supported branches: 3.4, 3.8, master -- correct ?
You can do it on master only and add backport labels which will trigger
the backports if there are no conflicts.
I don't think it's worth the effort of automating a transition to be
honest. This situation occurs so infrequently (once in the past 10
years) that it's unlikely to pay off. If you want to ensure the style
is future proof, then I'd suggest building it dynamically when
required, and doing it in c++. Then it's effectively guaranteed to
keep working and if anyone changes API, they'll need to fix your code
in order to build....
So not even python is API safe ?
It is stable throughout version 3.
Longer term, with C++ it's more likely that breaks are noticed just in
time, because the compiler is quite good at detecting incompatible api
changes.
Do you have examples of building style dynamically ?
Something like this
https://github.com/qgis/QGIS/blob/master/tests/src/python/test_qgscategorizedsymbolrenderer.py
?
Matthias
--strk;
() Free GIS & Flash consultant/developer
/\ https://strk.kbt.io/services.html
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer