On Mon, May 27, 2024 at 09:55:37AM +0200, Giuseppe D'Angelo wrote: > Hi, > > On 25/05/2024 13:03, apoenitz wrote: > > As an open source application developer I mostly care about SC, as SC > > breakages > > means actual work for/me/. > > To better understand: when you talk about SC, are you referring to literally > source compatibility (application can be recompiled with newer version of > Qt, without any source changes) or more in general to behavioural > compatibility?
In the text of my response I distinguished between source compatibility and behavioural compatibility, "SC" was refering to literal source compatibility. In any case, I see already this part of the discussion as indication that the focus is not where I as a user would have hoped to be: As a user I would like a library to be beneficial in some way, typically by saving me from doing similar work myself or finding/buying/.. elsewhere, minus, of course, the effort/time/cost/.. needed to use this library, including adapting my own code to other, usually newer, versions of the library. Ideally, the various compatibility guarantees would help, or even ensure, that such upgrades are cheap. Full source compatibility would e.g. save me from having to change my code at all, strong behavioural compatibility guarantee would save me from having to worry about my working applications to suddenly break. But, as mentioned, binary compatibility does not really help me much. This all is not white and black, the effort needed for the required adaptation scales with the severeness and the number of the compatibilty breakages. Often, /some/ effort to overcome those breakages is tolerable, for instance when other people/projects benefit in total much more from the new behaviour then I suffer. My problem currently is that I do not see that balance since ~5.12 anymore. Instead we have now an industrial scale process to deprecate stuff, giving me the choice of taking the pain of a thousand little cuts spread out over a few years be heeding all the warnings or to ignore them and take the heavy blow come 7.0. There are by now ~240 QT_DEPRECATED_VERSION_X_6_* in qtbase alone. Fixing them today involves touching thousands line of code in my code base(s). Very few of them are truly, clearly necessary. The bulk is "nice to have" or "should have been like that from the beginning (but the benefit is not sufficient to the drop the original)", and a few are just pain without (significant) gain. As an example for the latter: QCryptographicHash::addData() went from QByteArray plus ptr/len overload to a single addData(QByteArrayView bytes). Most of the existing uses were of the addData(reinterpret_cast<const char *>(&something), sizeof(something)) kind - ugly enough already, but now it needs an additional QByteArrayView() wrapped around. Why? Why can't the ptr/len overload just stay? One line, inline, on the library side? Because someone doesn't like raw pointers but a struct with a raw pointer and an int will save the world? Similarly, QString::fromUcs4() went from uint to char32_t. The first works well to interface with C89 code (and seriously, where else do you get UCS4 data from?). char32_t doesn't even exist in that world. So it's ugly casts to "fix" again, and again: what's the point of forcing thousands of people and projects to adapt to that instead of having /one line/, inline, on the library side? Now, these two cases require only mechanical changes, conceptually easy to do, but annoying and eating time that cannot be spend for actual improvements of the user's application. Others are worse, and I don't want to get started with the behaviour changes here. To come back to why I think the focus in the compatibility discussion is wrong: The topics there are simply irrelevant from the perspective of someone /only/ /using/ Qt: Whether something is foo-bar incompatible of type A or zig-zag incompatible of type B does not matter. For the user it matters how much effort it takes to get back to a working state after an update of Qt. And for us the discussion should not be foo-bar vs zig-zag, but /actually/ /helping/ users vs having fun with ivory tower discussions and processes. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
