I am pleased to inform that Qt 5.6.3 has been released today. As always with a patch release Qt 5.6.3 does not bring any new features, just error corrections. For details of the bug fixes in Qt 5.6.3, please check the change logs for each module and known issues of Qt 5.6.3 wiki page.
Qt 5.6 LTS is currently in the 'Strict' phase, and only receives fixes to security issues, crashes, regressions and similar. Since end of 2016 we have already reduced the number of fixes going into the 5.6 branch and after Qt 5.6 LTS enters the 'Very Strict' phase it will receive security fixes only. The reason for gradually reducing the amount of changes going into an LTS version of Qt is to avoid problems in stability. While each fix as such is beneficial, they are also possible risks for behavior changes and regressions, which we want to avoid in LTS releases.
As part of our LTS commitment, we continue to support the commercial Qt 5.6 LTS users throughout the three-year standard support period, after which it is possible to purchase extended support. For description of our support services, please check the recent blog post describing the Standard, Extended and Premium Support. In May 2017 we released Qt 5.9 LTS, which includes a wide range of new features, functionality and overall performance improvements. We expect to release Qt 5.9.2 patch release still during September, including all the bug fixes of Qt 5.6.3 and many more. To learn more about the improvements that come with Qt 5.9 LTS you can find all relevant blogs and on-demand webinars here.
If you are using the online installer, Qt 5.6.3 can be updated using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.
Commenting for this post has ended.
Is it requiring c++14 now?
error: unrecognized command line option "-std=gnu++1y"
@Rodrigo: C++98 is still the minimum requirement for Qt 5.6.
I heard that Qt has still 2000+ bugs. But 5.6.3 only fix 25 bugs?
As an example, Delphi was bought by a small company embarcadero, it work hard as you, every 6 months will release a new version. But in Delphi 2010, it fix 1000+ bugs. Not all new feathers are very interesting in 5.9/5.10, and the functionalities of Qt are enough for most work, So I think you should try to fix all bugs first?
@stlcours: Qt 5.9 LTS is the version we currently put all bug fixes, please use it in your new projects. Next release Qt 5.9.2 is expected to be out in ~2 weeks.
I guess what most developers want is, that you stop adding new features for some time, and spent all effort into bugfixing and testing till at least most bugs have been resolved...
Agree with you, digia should open a vote for commercial/non-commercial users, ask them what do they want from Qt5?Like
1 : More and more new features before bug fixes or focus on bug fixes first?
2 : If you prefer new features rather than bug fixes, which features you would like to see Qt5 implement?
Rather than adding more and more features, treat bug fixes as "second citizen" by your own measurement, please open your eyes and ears, listen to the voices of your users, ask them what are they really want?
@tham: What makes you believe we see bug fixes as a "second citizen"? We are continuously investing into maintenance and fix bugs. The effort spent in maintenance is higher than development on new functionality. Of course putting all effort into bug fixing would mean an increase. But there are also users asking for new features, so stopping all development is not feasible - at least for a longer period of time.
@Tuukka Turunen Have you studied the reply of the blog post(http://www.qt.io/blog/2017/...?) How do you explain the P1,P2 bugs listed at the post which do not get fixed after years? Instead of giving them any reply, you simply ignore and avoid them, how could you expect us to believe Qt are not treating bug fixes as "second citizen" with this kind of attitude?
>But there are also users asking for new features, so stopping all development is not feasible – at least for a longer period of time
If you cannot make everyone happy, then unless you should try your best to make most of the developers happy, that is why I say open a vote for commercial/non-commercial users..
Whatever, I do not think Qt5 should add more new features, the long standing tendency is for new bugs to be introduced at a much faster pace than old bugs are solved, every sane developers know this is a sign of dying, please focus on bug fixes first before you kill the goose that lays the golden eggs.
> I heard that Qt has still 2000+ bugs. But 5.6.3 only fix 25 bugs?
Bug tracker says there are 239 bugs fixed in 5.6.3
> As an example, Delphi was bought by a small company embarcadero, it work hard as you, every 6 months will
> release a new version. But in Delphi 2010, it fix 1000+ bugs.
Let's just assume for a moment that bug counts can actually be compared. Qt 5.6.3 is a patch level release. Delphi 2010 sounds more like a major release.
(And btw, Embarcadero has more than twice the number of employees than The Qt Company. Not that it should matter ...)
Nobody doubts that there are important bugs open. But that doesn't mean that we (as in Qt developers) don't care about, or don't spend time on fixing bugs is just dead wrong, and frankly speaking quite frustrating to be repeated so insistently. The people I work with definitely spend most of their time on triaging and fixing bugs.
>But that doesn't mean that we (as in Qt developers) don't care about, or don't spend time on fixing bugs is just dead wrong
We did not say you don't spend time on fixing bugs but suggest you should stop adding any new features but focus on bug fixed. If you can decrease total number of bugs on every release, today you wouldn't see so many developers arguing Qt should focus on bug fixes first.
I can ensure you there will be less and less users want to use new version of Qt, because every new version you release will add more and more bugs into your codes, last time I check there are less than 10000 bugs(p0~02), now the bugs are close to 12000, next time would it become 14000?
How many bugs could persuade Qt team should focus on bug fixes first?
The long standing tendency is for new bugs to be introduced at a much faster pace than old bugs are solved.
> I can ensure you there will be less and less users want to use new version of Qt, because every new version you release will > add more and more bugs into your codes, last time I check there are less than 10000 bugs(p0~02), now the bugs are close to > 12000, next time would it become 14000?
Your making the assumption that the number of bugs is directly related to the quality and usefulness of the product. I don't think this is that easy - bug counts also rise just by the number of users, broad of use and factor of time.
> How many bugs could persuade Qt team should focus on bug fixes first?
Well, I do think that we do fous on bug fixes first. That doesn't mean that we don't do any feature development though.
> The long standing tendency is for new bugs to be introduced at a much faster pace than old bugs are solved.
That's fine as long as the general usefulness of the product doesn't decrease.
To put this into an extreme: By the metrics of open bugs, the best product is something that a) just got released, and b) has no users. That guarantees that the bug count is zero.
I don't mean this as a killer argument to silence any discussion about quality and focus. But I consider the idea of "Do fix all bugs before doing any features" way to simplistic, and throwing number of bugs around does not help either.
@Kai Koehne I hope you are right and sorry for the harsh words. Besides, none of us ask you to fix all of the bugs first but fix most of the critical bugs(50%?80%)
Even number of bugs do not reflect quality directly, 12000+ bugs still do not give users good impression
Yes, I made mistakes. There are 239 bugs fixed for 25 modules. You work very well. But I hope you can continue until 5.6.10 or more... because there are still 12000+ bugs and that 5.6 is the last version for C++98 which is very classic. Good luck!
I told above only because I love Qt!
You can actually check the number of unresolved bugs here: http://bugreports.qt.io/ (project = Qt AND type = Bug AND resolution = Unresolved)
When Qt 5.6 LTS was released, LTS was your promise to users. Now you are saying, Qt 5.9 LTS is your new promise and you are not going to keep your old one? And you want people to do business with you?
@Alex: Nothing has changed in our LTS promise. Each LTS release has four phases: 1. Development, 2. Stable, 3. Strict and 4. Very Strict. See details from: http://code.qt.io/cgit/meta.... During Development and Stable phases all fixes go in. During the Strict phase we reduce the amount of fixes to the most important ones in order to avoid regressions. Finally in the Very Strict phase it is mainly about important security issues, should such appear. Qt 5.6 LTS is now in Strict phase and Qt 5.9 LTS is now in Stable phase. Due to the phasing all bug fixes go into Qt 5.9 now - just like they did to Qt 5.6 when it was in Stable phase.
Build of static libraries for iphonesimulator is broken in 5.6.3 (it works in 5.6.1, I did not test in 5.6.2); architecture is armv7 + arm64 instead of x86 + x86_64
I join to the many users who are not satisfied about the direction Qt is heading on lately. Quality is decreasing fast.
In real world we still need to target Windows XP or Mac 10.7 so Qt 5.9 is of no use.
I have subzero interest in QML and the likes but I want a solid Qt Core + Widgets that works!
Please fix bugs and maybe support again Win XP and older Macs otherwise many of us will be stuck with 5.6.x and maybe try to find alternatives to Qt.
@unhappy user: Have you considered using a later Creator and Qt version? The mobile platforms are changing constantly and it is not always feasible to keep up with them with old versions of tools and frameworks. https://bugreports.qt.io/br... is a known issue of Qt Creator 4.1.
About iphonesimulator bug: I am using latest Qt Creator and:
- Mac OS X 10.11 + Xcode 7
- Mac OS X 10.12 + Xcode 9
Create a project with two subprojects, one static lib and one app, the app use one fn from lib and depend/link with lib prj.
Qt 5.6.1 is OK, 5.6.2 is where the bug was introduced, 5.6.3 still buggy, 5.9.1 is OK (did not test between 5.6.3 - 5.9.1).
Having a project with multiple subprojects (apps + libs) is a common scenario and such a failure should not pass QA. Please include this in your test suite.
One question: it was said that Qt will be available as shared libs on iOS starting 5.9 then delayed to 5.10. Looking at 5.10 alpha it is still static. Any news regarding this?
What about ICU dependencies? I can't see DLLs in bin directory of 5.6.3, but they are in 5.6.2.
While some of my pet bugs are not fixed as fast as I would like, and some of my requested features are not yet there, many others are, especially since 5.9.1.
For XP and for Lion I have to keep seperate development systems with an old OS and an old development environment and Qt 5.5.1, yes, annoying, but also less and less needed.
If I could tell Qt what to do I would probably not say to put the resources at keeping Qt 5.9 compatible with Lion and XP, but to continue the balance of bug fixing, adding new features and improving the existing stuff, such as QML, which I see since Qt 5.8 and even more with 5.9.
I like also the LTS concept, 5.6 LTS is still a solid base, so nothing forces me to upgrade apps where 5.9 does not bring advantages, while on the other hand other apps can benefit from the new features and fixes in 5.9.x.
So yes, things could be better, as always, but unlike others above I see a constant improvement and a quite usable situation with which I can live.
Keep it coming, Qt!
@Kalileo: Thanks :)
These libraries are not included in 5.6.3 (Windows). Why?
icuuc54.dll
icuin54.dll
icudt54.dll
AFAIK no Qt library needs it anymore. Why do you miss it?
Sorry but I join the "fix bugs first" people.
I think the major mistake here is the 6 months release cycle. For example, 5.9.0 release was May 31st, while 5.10 feature freeze was August 8th. When developers code new features, they have to spend time to get them in good shape for a release and fix regressions. This leaves almost no time to fix what slipped in a previous release and contribute to a patch release.
How is it possible that one single developer has 981 bugs assigned to him ? (https://bugreports.qt.io/is...) I think that's ridiculous.
If you look at https://wiki.qt.io/Qt4ver... you'll see Qt 5 is nowhere close to that. Minor versions don't usually go beyond .2 patch version.
In short: IMHO if you release a minor version per year and do more patch releases, I think nobody will complain about it.
For the record: among 981 bugs, 490 are between P0 and P2. As a developer, with that amount of bugs I wouldn't even know where to start fixing stuff.
Hi Massimo,
in the case you mentioned (and also others) those bugs are assigned to this developer as he is managing the team responsible for that area. In the past it was decided not to have a "virtual" assignee like Team x,y,z but rather pinpoint someone responsible for an area and distribute those tasks among his team. Those tasks which have not been distributed stay within the manager.
But I agree it looks scary at a first look :)
Secondly, Qt is a huge project. This implies that while the time difference between a release and the feature freeze is small, it does not imply that all the team is either in feature development or bug fixing mode. Some features also take multiple release cycles to get implemented. Hence, while team 1 develops feature A, team 2 and 3 can still be in bugfixing mode. For the next release, team 1 is not doing features, but focusses on bug fixes of feature A they implemented in the release before. Hope this clarifies the process a bit.