Hi, Il 13/10/2018 09:03, Boudewijn Rempt ha scritto:
Then what else made it necessary to suddenly add lots of #include <QButtonGroup> lines?
I still don't get it, how is that possible?* If we're talking about a SIC internal to Qt, that is, some other part of Qt not building because of that change, that of course has to be fixed as part of the change itself (or immediately after). The fact that we're talking of a patch landed 2½ years ago makes me think this is not the case.
* If we're talking about a SIC against user code using public APIs, the commit does not touch any public header, so I fail to see how it could break anything.
* If we're talking about a SIC against user code using private APIs, or some 3rd party patches on top of Qt, they're obviously not covered by any source compatibility promise.
While the above is true in general, note that for the _specific_ case of breaking includes, Qt does indeed not guarantee source compatibility.
You're not supposed to rely on transitive inclusions through Qt public headers; if you need something, you must include the right header. This has always been the case; and this makes Qt free of add/remove/modify include from its public headers (e.g. turn an unnecessary inclusion into a forward declaration).
The policy of which source incompatible changes are allowed in Qt _public_ APIs is documented in QUIP 6:
https://code.qt.io/cgit/meta/quips.git/tree/quip-0006.rst
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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
