[Development] Behavior changes in Qt

[BRM]

> From: Sorvig Morten <Morten.Sorvig at digia.com>

>Subject: Re: [Development] Behavior changes in Qt
>On Oct 11, 2012, at 4:06 PM, BRM <bm_witness at yahoo.com> wrote:
>>> 
>> 
>> How about opt-in (via configure or extra flags) until the next major release?
>> I don't think doing the opt-in/opt-out/mandatory over several minor release would bode well for compatibility between minor releases, which is a big must.
>> 
>> For example, I have some software that is still running on Qt 4.5.1 in production; and component is running on Qt 4.7.4. Yet I need the behaviors in the overlapping code to be the same; without having to worry about getting the compilations right in both cases.
>
>If I understand correctly you are compiling a shared code base against both Qt 4.5.1 and Qt 4.7.4?  I agree that use case would be harder if there were significant changes between 4.5 and 4.7. There are still changes between them today though, in the sense that each bugfix usually comes with a change in behaviour.
>


Yes that is correct. I have a series of libraries that do things from networking to graphical interface to services. All of them need to run on well on Qt 4.5 and 4.7; I typically stay away from APIs that are newer than 4.5 to maintain compatibility. However, having something change under the hood of Qt that introduces a change in the existing APIs is not, IMHO, an option as it would break support for codebases like mine.


>One solution is workarounds based on the Qt version. We are running Qt Creator against both Qt 4 and 5 using QT_VERSION #ifdefs for example.


That works for Qt4 to Qt5, but it would not work if you had something subtly fix an API under the hood in a way that you cannot detect with QT_VERSION.


Having a configure option to opt-in for the fix makes it easy, but then you're not guaranteed the fix will be there for 3rd party provided versions.

Likewise for opt-out.

However, with opt-in, you can enable the support it you need it, and compatibility is much easier to maintain as you are compatible by default and if you need the fix you can apply it to your install.
So I'd say it would need to be 'opt-in' only until a bigger release that makes it mandatory; KISS is a very good principle.


In my case,  would not apply the fix for the version I develop with and provide to customers.


$0.02

Ben