Hi, On Wed, May 4, 2016 at 10:09 AM, Matthias Kuhn <matth...@opengis.ch> wrote:
> 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. > Yes, that Qt5/PyQt4/Py2 make sense during the migration period (6 to 12 months?). I think having Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for Mac is not unreasonable. This will help plugin authors and core testers migrate code, since all three could be installed on a dev Mac at the same time. > 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. > That sounds great, if we can find a way to do that on a nightly basis. Seems a bit excessive to do per Travis test build, i.e. per every commit and PR. Well, at least for full bundling, which takes a while and might clog the Travis queue. Another option is to do a minimum bundled build (just qgis libs/frameworks, Python modules and plugins). Then a user would need to have a Homebrew dependency install to work with the artifacts. That might be the simplest. It would be equivalent to the QGIS.app inside of the Homebrew qgis-214 prefix install, or ~58 MB compressed. Note, I do something similar at work already, though via Jenkins builds. Would make it VERY easy/fast to functionally test PRs on Mac. It will require the minimum Mac OS to be 10.9 (Travis-supported OS) instead of the current 10.7, but I was going to bump the nightlies to 10.9 anyhow, since anything less than that is not supported via 'bottles' upstream by Homebrew. Also, it's a totally reasonable minimum OS for a nightly. This seems like a good plan to me: * New Homebrew-based Mac bundling CMake routines have two bundling outputs: minimal and full * Travis Mac build produces a minimally bundled app as an output artifact, which requires a Homebrew install of deps to use * Generate fully bundled Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for local isolated testing of plugins and core Larry Shaffer Dakota Cartography Black Hills, South Dakota > 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 >
_______________________________________________ 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