On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: > > Hi, > > > > I have in the past fixed #include mistakes such as #include > > <qsharedpointer.h> for QSharedDataPointer, and even though each time the > > issue came up that this is a SiC change (but only for users that unduly > > rely on indirect includes), so far they were always accepted. > > > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come > > across many files that included qhash.h without using it, and likewise > > some > > for which qhashfunctions.h would suffice. One of them now got a -1 for > > being SiC. > > > > Can we please decide once and for all whether #include cleanups that are > > technically SiC are ok or not, if they only affect users that rely on > > indirect includes? > > > > My vote obviously goes to allowing them. > > My vote goes against such gratuitous SiC changes. > > Each little SiC changes add up in frustration for the developer who upgrades > its Qt version. > So when it is easy to avoid, we should avoid it.
I'm with Olivier on this one. Source compatibility is a key contribution to the success of Qt. For developers building their own software it may not be such a big deal, if they are experienced Qt developers. For somebody who just clones a random project off github and then tries to build it, such a "simple" source incompatible change becomes a deal breaker. I argue that there's a high probability that person is not familiar with these types of changes nor knowledgeable how to fix them. I've encountered this numerous times myself for example trying to keep the nvidia modules on my Laptop compiling with a changing kernel API. Often the fixes are _absolutely_ trivial one liners about missing includes. But I more often can't be bothered to dive into the source code to figure out what to add where. And then we have exactly the element of frustration that harms the product. Simon _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development