[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
addition.
Kevin Kofler
More information about the Development
mailing list