[Development] Deprecation/removal model going into Qt 6

[Manuel Bergler]

> 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.

My experience here is rather limited, so far I've only worked on two
commercial Qt projects at two different companies.  Both did not use
private APIs and yet upgrading took at least a few days, sometimes
even several weeks and always required source changes.

>
>
> > 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.

Due to Hyrum's law [0], even with stricter guarantees there will
always be someone for which migration is a non-trivial amount of work.
The only way to avoid that is to change nothing, ever. I personally
also don't understand why people would expect getting shiny new
features of a new minor release without having to pay a cost of
migrating their code over. I believe that as long as the benefit of
the new features outweighs the cost of migration then people will be
willing to migrate anyway. I myself don't mind the 2 weeks it took so
far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the
cost of progress...

However, since the cost of migration needs to be lower than the
benefit of the new features, there are some consequences:
    - Obviously, just because API breaks are allowed they still
shouldn't happen without good justification, e.g. only because an API
proved to be to easy to use incorrectly or to hard to use correctly
    - Make hard to find behavior changes API breaking instead, so that
the compiler helps with the migration.
    - Use inline namespaces so that old binaries will still run with
the new version of Qt and ABI incompatible libraries build with
different Qt versions fail to link instead of leading to seemingly
random runtime crashes.

Best
Manuel

[0] http://www.hyrumslaw.com/