On 04/05/16 16:49, Bas Couwenberg wrote: > On 2016-05-04 15:08, Matthias Kuhn wrote: >>> For the upstream QGIS packages this may be an option, for the official >>> packages in the Debian archive it is not. >> >> Understandable. >> >> I had a look at past Debian releases, extrapolating the release cycle we >> can expect the next release to happen in about a year. >> >> I don't expect a first QGIS release based on Qt5 to happen considerably >> earlier. The first LTR based on Qt5 will certainly not happen earlier. >> >> Just to make sure we talk about the same order of delays. (Note: this >> timeline has not been officially approved) > > Debian will switch to Qt5 with QGIS 2.16, otherwise there will be no > QGIS in the next stable release.
I don't want to prevent you from doing that, the worst that could happen is that you will need to set a CMake flag to void the non-existent warranty. QGIS will happily compile and run with any Qt5 version (for now). Just be prepared that: * Almost every plugin will fail (most of them with import PyQt and python 3 related errors) * Even if they are migrated anything related to NULL values will still fail because of the issue under discussion * This will be the case regardless of the approach to overcome this problem (Qt 5.7 or sip.enableautoconversion(false)) > The Qt4 builds currently still work because the Qt maintainers didn't > want to break QGIS before Qt5 support is available, but the Qt4WebKit > removal changes have already been committed and will be included in > the next upload. The upload may happen sooner than we'd like if > important bugfixes need to be uploaded in the near future. I'm happy to have Debian users as guinea pigs - but if you want to give the best UX instead of the latest bleeding edge code with known problems, you probably better continue shipping the current Qt4 builds wherever possible. I can try to see if there's another solution which only requires a sip update and not a Qt5 update which could possibly increase the number of possible target platforms. On 04/05/16 17:36, Larry Shaffer wrote: > I have started in on a complete rewrite of the CMake bundling for Mac > (leveraging BundleUtilities) that can utilize a Homebrew backend of > dependencies and generate a completely bundled app directly from a > Homebrew formula. When would be a good timeframe to start releasing a > Mac Qt5/Py3 nightly? > > Also, what would be the best nightly configurations for Mac to offer? > Qt4/Py2, of course, but what other combinations make sense, i.e. > Qt?/Py?, for testing? Or, should we focus only on offering two: > Qt4/Py2, Qt5/Py3? That is great news Larry. I would stick to Qt5/Py3 (and Qt4/Py2) to keep the matrix small and avoid plugins developed against strange combinations. In the case of OSX a combination of Qt5/PyQt4/Py2 may also make sense because I think there are Qt4 compatibility issues with OSX which this combination may overcome while still offering support for the current plugin ecosystem. But that's just a guess. What I am really interested in is a Qt5/Python3 OSX build on travis. The sooner we can have this the better. It could even have an on_success or deploy step to upload master builds from the test infrastructure. Regards Matthias _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer