[Development] Changing Qt's Binary Compatibility policy

[apoenitz]

On Fri, May 24, 2024 at 06:29:41PM +0200, Giuseppe D'Angelo via Development wrote:
> Hi,
> 
> One of the discussions at the past Qt Contributors' Summit was about our BC
> policy:
> 
> https://wiki.qt.io/Two-way_BC_in_Patch_Releases
> 
> We had a consensus for implementing some changes, but I don't remember the
> action points have been taken, so here we are.
> 
> 
> We propose to change Qt's BC policy as follows:
> 
> 
> 1) Qt continues to promise backwards binary compatibility for end-users
> within the same major version. Specifically, user code that is linked
> against a given Qt version will continue to work when linked against a
> version of Qt which
> a) is higher, and
> b) has been released later than the one used to originally link the code.
> 
> Details:
> 
> * "Qt" means the essential modules, except for QtTest. Addon modules may or
> may not promise BC (or even SC).
> 
> * "continue to work" just means that user code will be able to load and run
> with the newer version of Qt. We're not making any behavioural guarantees in
> this policy.
> 
> * "a higher version of Qt" means to follow semantic versioning
> (lexicographic / component-wise) ordering. For instance, 6.6.1 is higher
> than 6.5.5.
> 
> * "that has been released later": due to the branching policy / LTS / etc.,
> it is perfectly possible that a higher version of Qt has actually been
> released *before* one with a lower version number.
> 
> In the example above, 6.6.1 has been released on 27/Nov/2023, and 6.5.5 on
> 4/Mar/2024. Therefore, we _do not support_ upgrading from 6.5.5 to 6.6.1:
> 6.5.5 is allowed to have new symbols that are not present in 6.6.1, and
> would cause user code to fail to dynamically link/load.
> 
> (6.5.5 is also allowed to have some minor SICs, like the list of
> countries/languages in QLocale. 6.6.1 may have bugs that have been fixed in
> 6.5.5, thus causing regressions user code.)
> 
> 
> 
> 2) We stop guaranteeing forward binary compatibility within the same minor
> version.
> 
> In other words, code compiled against Qt X.Y.Z may or may not work if at
> runtime Qt X.Y.W is used, with W<Z.
> 
> Details: no user downgrades Qt and therefore has ever needed this. This is
> something that only Qt developers themselves have possibly needed -- seems
> to be a historical remnant at this point.
> 
> Concretely, this means that we can make our lives easier; for instance, when
> backporting fixes, we'll allow new symbols to appear in patch releases.
> 
> Does this sound good?


TL;DR: "Mostly Harmless", i.e. +/- 0 from my side.


----------

The longer version:

I believe the suggested change is harmless, as the current BC policy
(guaranteed BC in some cases, but neither source nor behavior compatibility)
already today does not actually help in a lot of cases anyway, so changes 
there cannot possibly do much harm: 

As an open source application developer I mostly care about SC, as SC breakages
means actual work for /me/. My applications target a wide variety of systems,
with varying Qt installations. Porting to specific system should be easy,
preferably not require patches to the sources, and I don't want to clutter my
code with Qt version #ifdefs, not just for readability reasons, but also
because realistically I won't test some code paths that way. For distributions
BC _might_ be interesting as it theoretically allows to update the libraries
without having to recompile the applications. Given the lack of behavioral
compatibility one would, however, assume proper testing of the result, and
the effort for that easily dwarfs the effort for recompiling the whole thing. 

As a closed source application developer I am often (more) free to target only
one specific Qt version, but there source incompatibily also means that I have to
spend extra time when switching versions, and I "of course" also have to test
for behavioral changes when doing so, again dwarfing any compile-time savings.
So no real gain either. 

So there's not much difference here, and I am not aware of other typical use
cases, i.e. effectively BC as such does not look like huge benefit in general,
and for me personally an as-large-as-possible degree of source compatibility
and strict behavioral compatibility (except for true bug fixes) would be a
/much/ better working environment.

Note that I am not saying that BC is useless. In the past it helped a lot, even
if not by itself, but by restricting people in making certain incompatible
changes. Together with a somewhat conservative mindset on what kind of
change is good in general this effectively meant for a long time that "it
just worked". This has changed in mid-Qt-5 times. We are now more willing
to break SC even for little, sometimes absurdly low, not measurable benefit,
we are more diligent to break SC while formally keeping BC, and the (IMHO far
too) easy to use "Pick-to:" mechanism means that not only desperately needed
fixes are backported but also a higher chance that fumbling affects "stable"
branches, effectively removing the indirect stability-enhancing effects that
the BC requirements had.

To summarize: If people feel strong about the need to "reduce" BC guarantees
because it impacts their personal workflows the change is in principle fine
with me, as it does not impact my personal workflow and none of the ones spelt
out above (i.e. pretty much everything that I'd call "reasonable"). So that by
itself could possibly be a +1. However, alone that "Therefore, we _do not
support_ upgrading from 6.5.5 to 6.6.1" will definitely come as surprise to the
uninitiated, shoving us into the "urm, quirky" corner, and the lack of formal
behavioral compatibilty promises makes the whole discussion rather academic
anyway.

In case we really want to _fix_ processes here I believe we need to step back a
bit a discuss first what kind of usecases and usage pattern we want to support
("painless maintenance" for starters?) and then try to derive formal rules from
that.

André