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é -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development