[Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6

Volker Hilsheimer volker.hilsheimer at qt.io
Wed Apr 7 16:11:34 CEST 2021


> On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> 
> On Mittwoch, 7. April 2021 15:18:10 CEST Giuseppe D'Angelo via Development 
> wrote:
>> Il 07/04/21 14:56, Sze Howe Koh ha scritto:
>>> Is it acceptable to remove them during Qt 6's lifetime? Or should we
>>> wait till Qt 7?
>> 
>> It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility
>> promise. And not marking things _in code_ but only in docs isn't good
>> enough.
>> 
> 
> We remove and change private API all the time. If it was declared
> deprecated long ago, we could argue it is kind of private in qt6.
> 
> 'Allan

But declaring an API deprecated requires two things:

* documentation marking it as obsolete
* QT_DEPRECATED_SINCE macro usage to trigger compile time warnings

QMessageBox::buttonText for instance doesn’t have said macro, and is not inline, so we can’t remove it without de-facto breaking BiC in a material way (since at least on Windows, the DLL found at runtime has to provide all symbols that the static import library had at link time, no matter if used or not).


So, what would be not only acceptable but desirable is a bunch of changes that add QT_DEPRECATED_SINCE to those methods that so far have only been documented as obsolete. And perhaps even a bit of qdoc tinkering to help us maintain consistency.

Volker






More information about the Development mailing list