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

[Allan Sandfeld Jensen]

On Mittwoch, 7. April 2021 16:53:16 CEST Henry Skoglund wrote:
> On 2021-04-07 16:11, Volker Hilsheimer 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
> 
> Hi, not to be a nitpick, but doing that stunt is possible on Windows,
> i.e. you can remove obsolete stuff from .dlls without rebuilding any
> app, if that obsolete stuff never is called.
> You can see what symbols/functions your .exe or .dll needs by doing a
> *dumpbin/imports* on it, and normally (unless you're crazy and call
> *all* functions in a library) the list of imports will be a subset of
> what the static import library provides/offers at link time.

Yeah, we wouldn't be able to remove private API if that wasn't the case.

Allan