> On 24 Aug 2023, at 14:43, Lars Knoll via Development > <development@qt-project.org> wrote: > > >> On 24 Aug 2023, at 14:30, Giuseppe D'Angelo via Development >> <development@qt-project.org> wrote: >> >> On 22/08/2023 23:27, Marc Mutz via Development wrote: >>> We have >>> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B >>> for backwards binary compatibility issues and we have >>> https://contribute.qt-project.org/quips/6 for acceptable and >>> unacceptable backwards source compatibility. >>> However, please keep in mind that the Qt project promises that we >>> maintain_forward_ BC and SC within patch releases: >>> https://wiki.qt.io/Qt-Version-Compatibility >> >> I'm a bit of a broken record here, but does anyone know the reason for >> having two-way binary compatibility in patch releases? > > There were mainly two reasons I remember why we have it: > > 1. It does in theory allow users to create an application binary that can run > against different patch level revisions of Qt. I think the idea here was to > make deployment easier on platforms that have a pre-installed Qt. This is > mainly Linux distributions. > > 2. It forces us to limit the changes made in patch level releases. > > Personally, I think both arguments have lost their value over time. > > If you really want to deploy against different versions of Qt, you should > simply compile your app against the oldest version you are planning to > support. That should cover case (1) in a better way and is much more in line > with industry practice. Argument (2) was good 15 years ago when we had rather > limited coverage by automated tests, but nowadays, this restriction might be > harming us more than it’s doing any good. > > I personally think it’s worthwhile discussing this and maybe modifying/easing > our policies here to some degree. > > Cheers, > Lars
On platforms where Qt is a system library, being able to at least launch your application if the system has a lower patch level than what the binary was built against sounds nice. But in practice, it’s rolling dice - the application might work fine; or it might get fatally hit by one of the not-yet-fixed bugs. And even if we definitely don’t want to add new API in a patch cycle (beyond what is being discussed here as exceptions), the commitment also stops us from overriding a virtual to fix a bug in a patch release. If there is no practical up-side to forward BC, then that is a significant limitation. I might be missing something; perhaps someone involved in Linux distribution work knows of arguments in favour of keeping the two-way BC commitment. We do have time at the Qt Contributors Summit to discuss this, and hopefully also some people with different perspectives present. So please add discussion topic here: https://wiki.qt.io/Qt_Contributor_Summit_2023_-_Program Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
