On Wed, 7 Apr 2021 at 22:14, Volker Hilsheimer <volker.hilshei...@qt.io> wrote: > > > On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen <k...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
