[Development] Deprecation/removal model going into Qt 6
Lisandro Damián Nicanor Pérez Meyer
perezmeyer at gmail.com
Sun Jun 2 18:56:36 CEST 2019
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.
More information about the Development
mailing list