Re: [Development] Updates to QUIP-6: Acceptable Source-Incompatible changes
On 16/12/2022 22:49, Marc Mutz via Development wrote: 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 header will continue to work as before. I would have never interpreted the SiC A rules as giving us permission to overhaul the content of our headers, because such a thing "can be worked around in user code without introducing Qt version checks". Sure, just `#include `, you'll never have a problem! Moving declarations from to should be unacceptable if it breaks users that only included , unless we've always documented otherwise (but even then, I'm not too keen on the "gratuitous" breakage...). If this needs to be spelled out in the QUIP, then sure, I didn't expect such a thing to be even remotely contentious. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updates to QUIP-6: Acceptable Source-Incompatible changes
On Fri, Dec 16, 2022 at 09:49:51PM +, 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 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
[Development] Updates to QUIP-6: Acceptable Source-Incompatible changes
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 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! Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development