Hi,
Short summary: The Qt Company has decided to focus development effort to 5.9
and dev branches in order to reach the planned timeline for Qt 5.9 release and
make improvements in the CI system. Next scheduled patch level release would be
Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security vulnerability
we would make Qt 5.8.1 directly based on 5.8.0 with just the security fix(es)
added.
Qt 5.8.0 looks to be a good and successful release. It has already been
downloaded 150.000 times even though it was released just two weeks ago. The
reception has been good overall and there are no blockers reported based on the
release. Qt 5.9 and subsequent releases will leverage the new configuration
system and other major improvements introduced with it, as well as add new
functionality to make Qt even better.
It took us a more time than planned to get Qt 5.8 out and because of that we
are already past Qt 5.9 feature freeze and approaching the alpha release soon.
Looking into the reasons why Qt 5.8.0 was delayed there are 3 items that had a
significant effect:
1. We did not keep the feature freeze properly as there were some items we
wanted to get in – doing so we should have replanned the whole release time,
but we tried to keep schedule and failed.
2. We were not able to focus enough to Qt 5.8 finalization as there was quite a
lot of effort going still to Qt 5.6.x and 5.7.x patch releases in parallel –
and our systems and processes are not yet good enough for this.
3. We have had some issues in the CI system that cause integrations to fail and
thus increase system load – these are now being addressed (getting new HW in
place, change to a better virtualization platform, use local disks instead of
central disk, reduce number of flaky tests, etc).
We believe it will be possible to significantly reduce the time from feature
freeze to release. To reach this we need to improve the items that have been
problematic with Qt 5.8 and other releases. After we have done the
improvements, it will be easier to keep the timelines and also be more
productive. We absolutely do not want to rush a new release out with severe
bugs in it – not now and not in the future – for this reason we want to focus
into the processes and systems part and allow more efficient release creation.
First we want to be able to reach the current 17 weeks timeline from FF to
release with Qt 5.9. After that we want to reduce it gradually to 10-12 weeks
(for a new minor release of Qt). Increased productivity will allow us to make
more patch releases than before.
In the CI system side we have major improvements happening during this year. We
will be purchasing more blades and other HW during H1/17, which will add
capacity, so we will be able to run more parallel integrations. We are also
looking into changing the system architecture away from central disk into using
local ssd for build machines. This is expected to bring improvements to both
performance and reliability (especially now as we have had issues with disks
failing despite the disk system still being in the mid of its life-cycle).
Third item we are looking into is change of the virtualization platform, which
we hope will bring improvements in stability as well as new capabilities.
Arranging enough time to implement the improvements in our systems as well as
keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately means
that we can’t make any scheduled patch releases until June, after Qt 5.9 is
out. We will keep the ability to release patch release for urgent security
vulnerabilities, as always. Such release would be on top of the previous patch
release and not include all other changes in the corresponding branch. Even
with a lot more help from community than before, making a scheduled Qt 5.8.1
release parallel with Qt 5.9 has impact to the system load as well as to the
work needed from the release team and others.
I am well aware that a Qt 5.8.1 release would be beneficial, but making one now
would impact Qt 5.9 schedule and our capability to improve CI system stability.
Qt 5.6.3 LTS patch release is done straight after Qt 5.9 release, but not
before. After the Qt 5.9.0 in May we should then focus into making Qt 5.9.1
release instead of making Qt 5.8.1 any more as Qt 5.9.0 is already out. With
the CI improvements in place, we should definitely be able to make more than
one patch release for Qt 5.9.
As a scheduled Qt 5.8.1 release is not planned, should we start pushing fixes
directly to 5.9 branch now? It would reduce the workload as we do not need to
first integrate changes into 5.8 and then merge upwards to 5.9. It would also
reduce the time it takes to get fixes into to 5.9 and dev as well as reduce the
load to the CI system as less integrations are needed. We can keep 5.8 branch
open for a while still similarly as 5.6 is in case there is some fix that must
be in the 5.8 branch. Let’s discuss in the next release team meeting (Tuesday
14th Feb 16.00 CET) if pushing fixes to 5.9 branch directly would be good
approach.
Yours,
Tuukka
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
