[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.
Andre'
More information about the Development
mailing list