Hi Richard, Thanks for the feedback, very interesting.
We have been working on a plugin qgis2compat [1] that aims at being a legacy layer, so you have to maintain only a single plugin. 1. Migrate to QGIS 3 2. Add some code to load the compatibility layer 3. Add missing compatibility fixes in the qgis2compat plugin This way one has to manage only a single - QGIS 3 compatible - plugin and incompatible calls are routed transparently to the appropriate QGIS 2 API. Without any if-version-branches inside your plugin code, so once the day comes you can just drop the qgis2compat plugin. Main advantage: * maintain a single codebase (!!) * the code is clean and targetted at QGIS 3 * the load for writing versioned calls can be mutualized between plugin developers https://github.com/opengisch/qgis2compat Cheers Matthias On 11/01/2016 08:03 AM, Richard Duivenvoorde wrote: > On 31-10-16 23:15, Nyall Dawson wrote: >> Given that you're probably the first to go through this process, I'm >> very keen to hear any further feedback you have on the porting >> process. What did you find hardest? Is the available api break >> documentation useful? Could we make it better? Do you have any >> suggestions on how we can make this process easier for plugin >> developers? > > One thing I learned: > > - IF you make use of a plugin Makefile (if you created a plugin using > the plugin builder), is to FIRST fix your make file (that is: > - point to .qgis3 directory instead of .qgis2 > - change pyrcc4 an pyuic4 to pyrcc5 and pyuic5 in your makefile > - make clean (to get rid of the Qt4-versions of your gui-py files and > resources > - run make again to have Qt5 versions of your gui-py's and resources > - and THEN run [QGIS-repo]/scripts/2to3 <yourplugin sources> > > Else you end up wondering why just half of your python files are 'fixed' > by the script :-) > > Other point to make: > - as a lot of deprecated QGIS code is removed: remove all the switches > you had for < 2.0 (if you have an old plugin :-) ), <2.6 etc etc > versions of QGIS, as this cleans up nicely > > - FIX all signal slot stuff to use the 'connect'/new way > > - I only had a couple of QGIS-api changes. But that is maybe still coming... > > - Often you can clean __init_.py (as that was used for the 'old' > waymetadata (which is now in metadata.txt), and I had to keep that for > very old QGIS version (my plugin should work from 1.8 onwards....) > > - maybe some notes about the Qt-wrappers and the future script? > > Some links to add: http://qgis.org/api/api_break.html > And please add other api change links... I think we should put these on > the frontpage of qgis.org.. I could not google them easy > >> I'd also like to echo your disclaimer that it's premature for general >> plugin developers to start porting their plugins yet (unless they >> enjoy redoing changes!). There's still many more changes planned >> before 3.0 is finalised. > > hear hear > > Regards, > > Richard > _______________________________________________ > 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 > _______________________________________________ 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
