On Thu, Nov 29, 2007 at 05:34:04PM -0600, Shawn Walker wrote: > I would add to that this little snippet: > > [quote] > Qt is backwards binary and source compatible within each major > release. This means that a program linked dynamically to e.g Qt 3.1.1 > will continue running with Qt 3.3.5 without the need to recompile. Qt > is not binary compatible between major versions such as Qt 2.x, Qt 3.x > and Qt 4.x etc. Qt is also not forwards compatible, meaning that > applications created with a newer version of Qt will not necessarily > run or compile against older Qt versions. > [/quote] > http://trolltech.com/developer/knowledgebase/560/
So that contradicts what Stefan said in 3.1 about QT not maintaining compatibility between minor (dot) versions. > and this one: > [quote] > 8. Qt breaks binary compatibility from version to version. Will such a > user-level inconvenience continue to be the case in the future and > what can it be done to avoid it? > > Harri Porten: Binary compatibility has only been broken two times in > Qt's history. Namely when switching to major version 2 and 3, > respectively. In between those shifts - the last one happened more > than two years ago - we have invested major efforts to keep > compatibility between minor releases. This mostly involves a robust > class design and educating every developer about the technical rules > to obey > [/quote] > http://www.osnews.com/story.php/259/Interview-with-TrollTechs-Harri-Porten/ And this goes even further in that direction, implying that no compatibility was broken when moving to 4.x. If both of those are the case, then the only reason I can see to ever want old versions is when someone wants specifically to compile against it as their "minimally supported version". Which suggests that stuffing development copies (.so links, headers, etc) of QT somewhere somewhat inaccessible makes sense, and keeping the latest and greatest up in /usr/lib (and the like) is also a tenable solution. Danek
