[Development] Changing Qt's Binary Compatibility policy

[Giuseppe D'Angelo]

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?

Thank you,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240524/38bd8e00/attachment.bin>