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