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

[Matthew Woehlke]

On 2017-03-16 19:26, André Pönitz wrote:
> 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)

1. You assume that distros never update packages outside of distro updates?
2. What about rolling distros?

> 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.

Addressed in Thiago's reply.

>> 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?

No bug fixes? No new features? Inability to update applications that
need the new features? Delay in developers being able to use new
features because their users don't have the latest version?

>> 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.

Right. My point is I think it's okay for Qt to not bend over backwards
to insulate its users from BC breakages of Qt's dependencies (in
particular, the C++ standard library), since the efficacy of that
"shielding" is debatable. I don't think it's okay to extend that to
license for Qt to break *its own, internal BC*, which is what your
previous post seemed to be implying.

On 2017-03-17 05:32, Viktor Engelmann wrote:
> We are talking about BC breakages that happen because of libstdc++
> BC breakages.

Are we? That wasn't at all obvious from André's previous message.

> I think it might be wisest to allow BC breakage under the premise that
> the major version number must change whenever BC is broken.

We already do that. (We also allow SC breaks between major versions.)

-- 
Matthew