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' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
