[Development] Use of std::function in Qt API

André Pönitz apoenitz at t-online.de
Fri Mar 17 00:26:20 CET 2017


On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote:
> On 2017-03-14 13:33, André Pönitz wrote:
> > In general, I am not overly sold on ABI compatibility promises. I personally
> > could live without and find SC of more practical value. The most important
> > "feature" of ABI compatibility guarantee for me is that it limits people from
> > doing overly excessive source-incompatible changes.
> 
> Distros are likely to care; a Qt BC break requires a mass rebuild of
> everything that uses Qt (which translates into lots of users needing to
> update lots of packages when Qt changes).

I am three steps away from understanding what you are saying:

I don't get why a library (Qt or anything else) BC break would cause a distro to
update packages outside their usual upgrade cycle (when most, or rather all, of
the packages will be recompiled anyway), nor, in case the distro did it
nevertheless, do I understand why a user would need to upgrade packages in that
case, nor, in case the distro *and* the user consciously decided to upgrade, why
that would be a problem.

> Distros may refuse to update Qt within a distro release as a result, which means
> users are stuck with older Qt for longer.

Yes, and, so what?

We are not talking about security problems. What is wrong with running a
half-year, or worst case maybe even a two year old version of some library
as base for the bulk of the applications?

> All that more or less already applies to the standard library however (probably
> most distros don't accept a standard library BC break without a mass rebuild
> anyway), so Qt insulating against BC breaks in the standard library is maybe
> less necessary.

That was the starting point here. Not Qt breaking BC by itself, but allowing C++
BC breakages to affect otherwise "pure Qt" applications.

Andre'



More information about the Development mailing list