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_ReleasesWe 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.dang...@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
smime.p7s
Description: Firma crittografica S/MIME
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
