[Development] Deprecation/removal model going into Qt 6

Kevin Kofler kevin.kofler at chello.at
Sun Jun 2 10:41:25 CEST 2019

Manuel Bergler wrote:
> Right now, even though the API and ABI are stable, I have never seen an
> update to a new minor version of Qt5 that did not require source changes
> due to changed behavior,

Well, that depends pretty much on the individual project (how large it is 
and what parts of Qt it uses). Some projects indeed keep having to be fixed 
regularly, others just work unchanged throughout all of Qt 5.x. (In some 
extreme cases, even moving from Qt 4 to Qt 5 did not require any changes 
outside of the build system.)

As far as I can tell (I was a Qt comaintainer in Fedora for years and I am 
still involved in Fedora packaging and in IRC contact with the current Qt 
maintainers), the Fedora Qt packagers' experience is that bumping to a new 
5.x branch usually only requires rebuilding (usually without source changes) 
the known abusers of private APIs, and then occasionally fixing a handful 
packages that get reported to us (either by users encountering regressions 
or by the upstreams themselves warning all distributors), but most packages 
keep working without even a rebuild. Only occasionally, there were Qt bumps 
that caused enough issues to withhold them from stable release updates.

> so fixing a few calls that no longer compile doesn't increase the cost of
> updating all that much. As a matter of fact, fixing source
> incompatibilities is in my experience much easier than figuring out why
> behavior has changed, since I don't even have a starting point where to
> look in the latter case.

But that is pretty much an argument for even stricter compatibility 
guarantees, also forbidding at least some behavior changes. (I understand 
that sometimes, fixing a bug or even a security issue requires a change in 
behavior, but it should be avoided.) Laxer compatibility rules will just 
make it worse, because the behavior changes will not disappear without a 
rule banning them, you will just have to fix source incompatibilities in 

        Kevin Kofler

More information about the Development mailing list