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

[Sze Howe Koh]

On Wed, 7 Apr 2021 at 22:14, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
>
> > 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

https://bugreports.qt.io/browse/QTBUG-92480
https://bugreports.qt.io/browse/QTBUG-92481


Regards,
Sze-Howe