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

Reply via email to