On 27-02-16 09:42, Jürgen E. Fischer wrote:
> On Fri, 26. Feb 2016 at 21:10:24 +0100, Sebastiaan Couwenberg
> wrote:
>> If we cannot QGIS 2.14 with Qt5, we'll have to stick to Qt4 a
>> little longer. Because of the expected 2 month postponement of
>> the freeze due to get kernel 4.10 into stretch [1], we should be
>> able to get QGIS 3.2 into stretch that is planned for October
>> 2016.
>
>> http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
>
>>
> That didn't reflect the latest developments.
>
> For QGIS3 we don't have dates scheduled. We'll release a 2.16 in
> four months, that should have dual Qt4/PyQt4/Python2 and
> Qt5/PyQt5/Python3 support. After that we start working on QGIS3
> that'll be Qt5/PyQt5/Python3 only and API breaks (cleanups,
> extensions...). Once it's there, we'll return to a release
> schedule with fixed dates.
Thanks for the updated Release schedule.
The expected 8-12 months after 2.16 to get 3.0 ready makes it clear
that it won't be ready in time for the (postponed) freeze, but that
shouldn't be an issue because 2.16 will be ready in time and should
allow us to switch to Qt5 too without having to disable the bindings.
The first build of 2.14 with Qt5 failed due to errors in the
spatialite provider ('DetachFromResultSet' is not a member of
'QSqlResult'), this looks like an incompatibility with
libqt5sql5(-sqlite). I've disabled QSpatiaLite to work around this for
now. The second build failed due to errors in the globe plugin because
it doesn't have /usr/include/x86_64-linux-gnu/qt5/QtOpenGL in its
include path for QGLWidget, the Globe plugin has likewise been
disabled. The third build failed due to errors in QGIS server because
QtNetwork/QFtp is no longer available in Qt5, also disabled for now.
These changes allow the build to succeed with Qt5.
Because packages in unstable will be synced into Ubuntu I don't want a
severely feature reduced qgis in Debian unstable just to close the RC
bug. I'd rather downgrade the severity to important as long as the new
python-qt4 without the Webkit module hasn't been uploaded to unstable.
In the mean time we can still build with Qt4 and get qgis 2.14 into
testing and backports.
If the dual Qt4/PyQt4/Python2 and Qt5/PyQt5/Python3 support can be
backported to the 2.14 LTR branch we don't have to switch to 2.16 for
its Qt5 support. We can then keep using 2.14 LTR for unstable, testing
& backports. If not, we'll just switch 2.16 and get the next LTR in
all three. It's not ideal for stable users to have a non-LTR release
in backports, but it shouldn't be a blocker either.
Based on the results of the Qt5 builds, I'm in favour of sticking to
Qt4 for QGIS 2.14 for the time being. We won't be able to close the RC
bug, nor update qgis in testing and backports. But we'll have a much
more useful qgis in unstable and whatever the next Ubuntu release
after xenial is going to be (yeasty yak?). I expect the Qt4 WebKit
changes to be adopted by Ubuntu too, so we're likely to also need the
Qt5 support in QGIS for the Ubuntu builds.
I should probably file bugs for the Qt5 related build failures if they
haven't been reported yet.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Attachment:
signature.asc
Description: OpenPGP digital signature