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

André Pönitz apoenitz at t-online.de
Tue Nov 22 01:06:00 CET 2016


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.

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

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

Andre'



More information about the Development mailing list