[Development] Binary incompatible changes to Qt 4.8

Stephen Kelly stephen.kelly at kdab.com
Thu May 24 09:09:14 CEST 2012

On 24.05.2012 00:41, Girish Ramakrishnan wrote:

> On Wed, May 23, 2012 at 2:00 PM, Giuseppe D'Angelo wrote:
>> On 23 May 2012 20:03, Girish Ramakrishnan wrote:
>>> Hi Andreas, On Wed, May 23, 2012 at 11:12 AM, Andreas Holzammer
>>> wrote:
>>>> Hi, I wanted to backport the support for Windows 8 to Qt 4.8, 
>>>> which
>>>> is already done for Qt5 in
>>>> https://codereview.qt-project.org/#change,22940 With this
>>>> change a symbol is added and therefore binary compatibility is
>>>> broken. I know i cannot do that for Qt 4.8, so my question if we
>>>> should do this anyhow or how we want to handle this.
>>> That change preserves BC (enums don't create symbols either). It
>>> only breaks SC between patch releases which we avoid. I think it's
>>> fine to backport it and mark the enum with internal for qdoc.
>> But that breaks the purpose of the patch: having a public&documented
>> way for Qt apps to detect if they're running under Windows 8.
> I thought the main purpose was to let Qt know about the existence of
> Windows 8. Usually, code in Qt usually just does >= VISTA.
> But if the goal is for the user to use it, then yes, we have a 
> problem.

We discovered this issue when attempting to use cmake on Windows 8, 
parses the output of qmake --version, but isn't tolerant enough to 
the presence of the warning.

CMake of course needs to be patched for that, otherwise the already 
Qt versions won't work on Windows 8 (I don't know if they do work 
but the tolerance is required regardless).


>> Generally speaking, are there no plans of going towards 4.9 for this
>> kind of things? Or slightly change the policies for what regards 
>> 4.8?
> I would actually like to see a 4.9.

I also prefer not adding backward source incompatible changes to Qt 
4.8. Is
there any precedent for doing it though? Do we know for sure whether it 
binary incompatible or not to add an enum value?

> At the very minimum, a master
> branch in qt4 repo would be nice to have. But the logistics both
> creating a minor release (and post minor release) will require
> somebody to step up and invest a lot of time. Do we have someone who
> can invest such time there? Otherwise, it only makes sense to change
> our policy a little.

I don't know anything about why creating a minor release is more 
than creating a patch release, so I can't comment there.


Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

More information about the Development mailing list