[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 21, 2016 23:57:07 André Pönitz <apoenitz at t-online.de> wrote:

> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
>> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
>> [snip]
>> > - people using Qt in applications distributed by packaging
>> >   systems (read "Linux distributions"). They are not affected
>> >   by BC breakages.
>> 
>> Users might not notice if we maintainers have to deal with this nightmare.
>
> That's what I said.
>
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

And how many applications are Qt only and use no standard lib anyway? Are there any numbers? Yes, sometimes they are inlined but sometimes they are not. Is it really a so big burden for you? And what are you doing about GTK? To my knowledge their BC is quite limit. 

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
>
> I understand that.
>
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
>
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

You can capture behavior changes by unit and integration tests but there is always the possibility that you break something because the complexity is not reasonable testable. It's always a tradeoff. 

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
>
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?
>
> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.
>
> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I strongly agree with Andre'. And is a BC break in the time of flat pack that bad? As an user I really looking forward to flat pack,  so I can update my heavily used Applications and being not dependent on distribution. This package could be much better optimize with LTO and profile guided optimization. Maybe sharing everything is not that smart anymore. 

> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development