Hi,
I think in the interest of our users and the popularity of Qt, the maintenance of source compatibility should be a supremely important goal. That said, breakages of source compatibility for the sake of cleanups appear to have been accepted by approvers in the past. I think if we allow source compatibility breakages like the one here (overloaded slot added), then I think it should require a prominent notice in the changelog / release notes. One can argue that with includes it's pretty easy to "fix" the error, but with the QObject::connect error on ambiguous overloads the error messages are crap and I think we should make an effort help our users. Simon ________________________________ From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> on behalf of Jędrzej Nowacki <jedrzej.nowa...@qt.io> Sent: Wednesday, July 13, 2016 1:39:19 PM To: development@qt-project.org Subject: Re: [Development] Source break policy for function overloads On Wednesday 13 of July 2016 10:44:13 Alexander Blasche wrote: > Hi, > > Yesterday, I stumbled over a break in QtSerialBus due to the addition of new > QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by > > https://codereview.qt-project.org/#/c/160889/ > > Unfortunately this has the undesirable side effect that lines like: > > q->connect(q, &QModbusClient::timeoutChanged, element.timer.data(), > &QTimer::setInterval); > > do not compile anymore. The function pointer to setInterval() becomes > ambiguous. While the fix (https://codereview.qt-project.org/#/c/165034/) > was not difficult once you know what is happening this can hit every > customer and basically reduces the source compatibility promise into > absurdity. > > While talking to several devs in the office I could not find a congruent > opinion on this issue. Do we or even can we care? Do we have a policy? > > -- > Alex > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, We do not have SC promise only BC. We tend to not break SC without reason, for example we avoid juggling with header files just to "cleanup" stuff, but definitely we reserve right to add overloads and new functions. That is the current state, whatever it make sense or not is a different discussion. Cheers, Jędrek _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development