> On 29 May 2024, at 05:30, Kevin Kofler via Development > <development@qt-project.org> wrote: > > Giuseppe D'Angelo via Development wrote: >> 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. > > Hmmm… I do indeed think that this can help getting some bug fixes backported > more easily, and indeed, within one (GNU/Linux) distribution, we normally > care only about backwards compatibility, not forwards compatibility.
Guilty as charged for not following up on last year's Qt CS discussion by sending the email to the mailing list to put forth a specific proposal - also because we very last minute (and evidently after the note taker had closed his laptop) had some new concerns raised. - a 6.5.5 release might introduce symbols not present in 6.6.1 (but presumably present in 6.6.2, released chronologically after 6.5.5) We can explicitly exclude support for this upgrade path. - 3rd party, binary-only libraries A user project might use several binary-only libraries that have been built against different patch levels of the same minor Qt version. This is where things might get hairy. I don’t know how. One of those binary-only libraries might suffer from all sorts of issues when it runs against version of Qt with fewer bug fixes, but at least the symbols should be satisfied. My larger concern is that for patch releases, we have no processes to avoid that we end up adding poor APIs. We don’t do a header review, and we don’t have a whatsnew documentation file. The changelog should be enough for the kinds of things we are presumably talking about here. But agreeing to this will give ourselves the freedom to add new symbols within a patch cycle, so we should perhaps narrow this down a bit. - must fix a P1 bug - add symbols required to support new platforms (e.g. new QOperatingSystemVersion constants) or otherwise realities out of our control (e.g. new locale enum values - not a symbol anyway) - doesn’t touch any template code, because otherwise we *must* have a header review ;) Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
