[Development] Total cost of compatibility breaks (was: Re: Changing Qt's Binary Compatibility policy)

[apoenitz]

On Tue, Jun 18, 2024 at 04:53:32PM +0200, Giuseppe D'Angelo via Development wrote:
> Hi,
> 
> On 18/06/2024 10:15, Alex Blasche via Development wrote:
> > Our biggest issue is the adoption of Qt by users moving from one major
> > release to the next. The deprecations start to become a liability and
> > while they keep SC compatibility in check for Qt 6 they become a serious
> >   concern for any adoption of Qt 7. While doing changes when it is
> > necessary is OK as part of a major patch release, I totally agree with
> > Andre that a lot of deprecations are nice to have and not mandatory. I
> > would like to propose a far more restrictive process on when a
> > deprecation is accepted (unless somebody has a better idea on how to
> > curb this flood gate any other way).
> > 
> > If you need any further prove of the seriousness of this problem, have a
> >   look at how long it took for KDE to adopt Qt 6 or look at the still
> > incoming issues for Qt 5.15. Based on what I see, performance
> > differences are the most common reason why Qt 6 is not ported to. The
> > second one is the effort to port to Qt 6 due to mechanical porting from
> > one API to the next.
> > 
> > Qt 7 deprecations show an alarming trend and those mostly don't even
> > involve truly needed architecture changes like potential QIODevice or
> > QFileSystemEngine changes yet. (I only use these two classes examples to
> >   highlight the point and not that there is actual work being decided or
> > ongoing)
> 
> I think this is now effectively a separate thread of discussion, since these
> deprecations create source incompatibilities, not binary incompatibilities.

We can indeed discuss this separately (at least change the subject line), but
my main point in this part of the discussion is that users are to a large
degree not interested in this technical distinction of binary compatibilty,
source compatibility (type A and B) or behavioral compatibility, but they are
very much interested in the total costs of overcoming /all/ these compatibility
breaks to keep /their/ project alive.

At a high level, there is no conceptual difference between the costs for a
patch to overcome a SC break and the costs to overcome a BC break. It's simply
costs.  Compatibility breaks, of any kind, are a burden.  Some may be justified,
some not, but even for the justified ones there is a limit.  At some time a
straw will break a camels neck / tr("läuft das Fass űber") / ... 
In this - a users's - world, types compatibility breaks are kind of "equal",
and it does not really help to have elaborate rules on BC while SC is
considered fair game.

So, to be explicit, for your original question about two-way-BC in patch
releases: yes, fine, also with me, go for it, however, please be aware that
this is mostly irrelevant for The Compatibility Problem. And I probably
should feel guilty about kind of hijacking this thread.

> Should we discuss it at the QtCS in a couple of slots?

Definitely.

Andre'