[Development] BC/SC in patch releases

[Volker Hilsheimer]

> On 24 Aug 2023, at 14:43, Lars Knoll via Development <development at qt-project.org> wrote:
> 
> 
>> On 24 Aug 2023, at 14:30, Giuseppe D'Angelo via Development <development at 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