zander at planescape.com
Mon Sep 9 14:44:32 BST 2002
On Monday 09 September 2002 10:30, Reginald Stadlbauer wrote:
> On Monday 09 September 2002 09:57, Simon Hausmann wrote:
> > On Sun, Sep 08, 2002 at 01:39:02PM +0200, Matthias Ettrich wrote:
> > > On Saturday 07 September 2002 00:22, Dirk Mueller wrote:
> > > > There are some binary incompatibilites in the new moc code.
> > >
> > > There are? Where?
> > There are no real binary incompatibilities in the moc code (except
> > three binary incompatibilities in Qt itself, which are already
> > reported though :)
> > But the fact that newly generated moc code references the new
> > qt_static_property symbol from the base class essentially means that
> > kdelibs has become binary incompatible for third-party developers as
> > soon as they upgrade Qt, because they can't continue to develop
> > their application without recompiling kdelibs (in order to get the
> > new symbols referenced by the moc code in their own app) . That's a
> > major headache IMHO.
> This is only a problem if one updates to qt 3.1, does not recompile kdelibs
> but recompiles his/her own app with qt 3.1. Is this really a very likely
> scenario? If you only update the qt lib and link kdelibs + app agains it it
> is fine. If you recompile everything, of course there is no problem either.
This kind off throws out the concept of binairy compatability in KDEs major
versions; I can't run a product I bought from a 3th party developer on a
machine with Qt < 3.1 (if it has the need for Qt3.1)
Seems a logical constraint for an application; but upgrading is not enough,
you need a newly compiled kdelibs agains that version of Qt :(
How can we tell those developers we promised BC during the whole KDE 3.x
series that even before 3.1 is released the BC is being broken allready;
"Sorry not our fault!" ??
If nothing else; its a really big PR problem.
Thomas Zander zander at planescape.com
We are what we pretend to be
More information about the kde-core-devel