The same stabilization problem will occur for *any* upgrade like that. There's a lot of code (millions of it), thousands of commits between each minor release, with new features/reworks/etc. Breakage is inevitable. Granted, I expect the hop from 5.2 to future releases to be a bit calmer (no new js engine in QtQuick), but if we hadn't put the work into testing & stabilising now, we would have at some point in the future. As for "why are you upgrading at all instead of stabilizing?" - minor version upgrades aren't just for all new and shiny things. Attention from upstream (& everyone else) doesn't stay on old releases indefinitely. 5.0 (and 5.1, which we are on now) has missed so many security fixes at this point it's ridiculous. We backported some, but I'm positive we missed plenty of others. Here's an example of how contributions to each branch changes over time: http://www.macieira.org/~thiago/qt-s...h.absolute.png 4.8 is in a slightly better position here in that it's the last release of the 4.x line - it's not going to get any API changes etc, it's purely fix only. Plus the rate of change is significantly lower. So it's easier (and safer) to upgrade from 4.8.x to 4.8.x+1. For some graphical examples of what I'm talking about: https://www.openhub.net/p/qt5 - size and contribution rate to Qt 5.x https://www.openhub.net/p/qt - size and contribution rate to Qt 4.x [edit: also, Morpog's comment was pretty good]