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

2022-12-17 Thread Giuseppe D'Angelo via Development

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

2022-12-17 Thread A . Pönitz
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

2022-12-16 Thread Marc Mutz via Development
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