[Development] Source break policy for function overloads
Simon.Hausmann at qt.io
Wed Jul 13 15:55:20 CEST 2016
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.
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Jędrzej Nowacki <jedrzej.nowacki at qt.io>
Sent: Wednesday, July 13, 2016 1:39:19 PM
To: development at qt-project.org
Subject: Re: [Development] Source break policy for function overloads
On Wednesday 13 of July 2016 10:44:13 Alexander Blasche wrote:
> Yesterday, I stumbled over a break in QtSerialBus due to the addition of new
> QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by
> Unfortunately this has the undesirable side effect that lines like:
> q->connect(q, &QModbusClient::timeoutChanged, element.timer.data(),
> 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
> 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?
> Development mailing list
> Development at qt-project.org
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.
Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development