On 02/18/2012 04:13 PM, Darrell Anderson wrote:
>> On my current TDE 3.5.13 build, it looks like the QT
>> > 3.3.8.D, that I've packaged as an update to the
>> > distro-provided QT 3.3.8.B, makes some legacy QT3 programs
>> > crash, but I do not know why.
>> > As I understood, QT 3.4.0 for future TDE R14 will officially
>> > break compatibility with QT 3.3.8, so having both QT3.3.8.B
>> > and TQT 3.4.0 at the same time is mandatory for me.
> As I recall, whatever was done from 3.3.8.c to 3.3.8.d was strictly Trinity related and broke backwards compatibility. Our own Qt3 change log is, um, vague as to the specific changes and the reasons for breaking backwards compatibility. Regardless, KDE3 apps cannot use Qt3 3.3.8.d. Non KDE3 Qt3 apps might still work, but would need to be recompiled against 3.3.8.d rather than the original 3.3.8.b.
> 
> In our proposed FAQ we discuss backwards compatibility but we really do not address the technical aspects. :(
> 
> Darrell

I hate breaks in backwards compatibility, but I understand enough to know that
sometimes it is unavoidable. However, when a break is required, we must all be
diligent in identifying those programs that are broken by it and restore/rebuild
them to prevent losing functionality.

Progress is fickle. How much progress is there if for instance a gcc change
breaks a decade worth of software compatibility requiring millions of
applications to be updated just to build again? The gcc 4.5 constructor change
requiring all code with TQString::TQString() to be changed to TQString(). I'm
sure it made sense for the future, but what a PITA...

-- 
David C. Rankin, J.D.,P.E.