[Development] Updates to QUIP-6: Acceptable Source-Incompatible changes

A. Pönitz apoenitz at t-online.de
Sat Dec 17 13:51:06 CET 2022

On Fri, Dec 16, 2022 at 09:49:51PM +0000, Marc Mutz via Development wrote:
> Hi,
> The recent episode with qVersion() moving from qglobal.h to 
> qlibraryinfo.h, a header not included in qglobal.h, has shown that 
> QUIP-6 SiC A are too broad a category. As per QUIP-6, I'm proposing to 
> add a new entry to the table that bans moving definitions from one 
> header to another if the headers don't include each other. Optionally, 
> we may allow this for classes, because the <QClass> header will continue 
> to work as before.
> I'm also proposing to add a sentence that SiC B's can be made acceptable 
> if they're hidden behind opt-in macros. This just spells out existing 
> practice, to wit QT_NO_FOO, QT_CONFIG(foo), or QT_DEPRECATED_SINCE.
> The changes, in order:
> - https://codereview.qt-project.org/c/meta/quips/+/449444
>    (editorial, numbers the rows in the table for easier reference)
> - https://codereview.qt-project.org/c/meta/quips/+/449445
>    (mentions opt-in mechanisms)
> - https://codereview.qt-project.org/c/meta/quips/+/449446
>    (bans moving definitions from one header to another)
> - https://codereview.qt-project.org/c/meta/quips/+/449447
>    (exception for class types)
> Please discuss!

Instead of pre-declaring fine-grained rules on what might be ok or not
that backfire like the previous set we should rather (re-)establish
consensus on whether incompatible changes should be part of normal
operation in Qt development or whether this is a generally undesirable
activity that should only happen in case there's something unfixably
"wrong", or at the very least has a significant gain.


More information about the Development mailing list