[Development] Deprecation/removal model going into Qt 6

[Manuel Bergler]

Am So., 2. Juni 2019 um 18:56 Uhr schrieb Lisandro Damián Nicanor
Pérez Meyer <perezmeyer at gmail.com>:
>
> Hi! With my Debian maintainer hat on:
>
> On Sun, 2 Jun 2019 at 05:21, Manuel Bergler <berglerma at gmail.com> wrote:
> >
> > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <kevin.kofler at chello.at>:
> >>
> >> Volker Hilsheimer wrote:
> [snip]
> >> Your proposal to break ABI at every 6.x minor release would be an absolute
> >> nightmare for distributors. It would no longer be possible to upgrade stable
> >> releases of a distribution like Fedora to a new Qt as is frequently done
> >> now. Rolling-release distros would also suffer, having to go through a
> >> coordinated mass transition each time. And third-party PPAs upgrading Qt for
> >> a stable distribution would also become harder to offer (because they would
> >> have to rebuild ALL Qt-using packages, not just those (ab)using private
> >> APIs). I do not see how this would be an improvement over the current
> >> situation at all.
>
> Same goes for Debian, Ubuntu and (¿the vast majority?) of distros out there.
>
> > There are at least two ways Qt and/or distributors could deal with ABI incompatible changes in minor releases of Qt 6. First of all, Qt itself could make use of inline namespaces to ship several version of the same classes in the same binary while keeping source compatibility. And if Qt doesn't want to go that route because of maintenance overhead then the distributors themselves could decide not to ship just a single version of Qt, but rather have multiple versions side-by-side using the custom namespace and library infix option already provided by Qt.
>
> In both cases it's a great burden. In one case in the Qt developers's
> shoulders (much worse that keeping API/ABI stability) and in the other
> in maintainers's shoulders. On the the **great** things Qt provides is
> actually API/ABI stability. I do understand that maybe it's not seen
> by many, but indeed is one of it's major strengths.

I can see the point that for distribution maintainers API and ABI
stability are great assets. But I also think in the long term it will
kill Qt as it prevents Qt from evolving. We don't want to have too
many breaking changes at once when upgrading to a new major version,
because that will lead to slow adoption as the benefits of the new
features does not outweigh the cost of updating for at least the first
few minor releases. Yet, with the current model, we also can't have
breaking changes in minor releases, so effectively nothing can ever be
changed.

The best example I think is the QList discussion. It is almost
universally accepted that QList is bad, yet even there we can't seem
to get consensus to just get rid of it with no replacement and having
the users deal with it. Not being able to remove badly designed
classes and APIs will cause them to be used even in newly written code
when the next major release is around the corner, thus - by induction
- needing to be maintained (and taught!) indefinitely.

Best
Manuel