[Development] QProperty and library coding guide

[André Pönitz]

On Wed, Jul 22, 2020 at 10:24:21AM -0700, Thiago Macieira wrote:
> On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> > How often do we think people are actively taking advantage of Qt's BC
> > promise (and how often do we hold this promise, and how often is this
> > relevant as we do not promise to change behaviour while keeping BC)?
> 
> That is a good question. I don't want to minimise it, just to add.
> 
> Have at least one category of users that require it, that being the Linux 
> distributions.
> So long as we support them, we have to provide a way to have 
> BC. And if we do have such a way, how much does it hurt to extend it 
> everywhere?

How much of a *hard* requirement is that in practice?

If Qt would bump major versions once a year, and take that as a chance to
break BC, would that be a problem, if so, why?

Because distributions have a large set of packages that are not
rebuild at least once a year? Or because users have a few hundred
packages that they don't want to update otherwise?

> We've seen users of not-systemwide-Qt-OSes having BC issues too. Large 
> projects often have binary artifacts they'd rather not recompile every time. 

"Every time" would be something as or less frequent than the current minor
release cycles, i.e. twice per year, or less frequent.

> Those teams can be taught to recompile, but that's not their current practice. 
> Breaking BC means subtle errors that are hard do detect and debug.

Right. But at the same time we accept behaviour changes which can lead to
similar subtle errors that are hard to detect and debug as well. 

I see no real conceptual difference here.


> Finally, there's the issue of binary-only components by third parties. If we 
> ever want to support such an ecosystem (we could call it "Qt Marketplace"), we 
> must have as few binary-incompatible versions as possible. It's already 
> difficult to support, for desktops alone:
>  - Linux GCC 64-bit
>  - Apple Clang 64-bit [*]
>  - Windows MinGW / Clang 32-bit
>  - Windows MSVC 2019 / clang-cl 32-bit
>  - Windows MSVC 2019 / clang-cl 64-bit

I'll argue that a robust, binary-only distribution of independent, but interacting
components does not work in practice. If it would, the Windows ecosystem would
have invented that during the last 30 years or so. Instead we have rather
monolitic fat applications there, with components shared at most within a given
vendor's own product line, with really rare exceptions.

> Breaking BC frequently means replicating this table for every BC breakage 
> level.

Or have the input channel accept source code and build the binaries automatically.


In any case, I don't think either use case is an absolute reason for keeping BC.

Andre'