[Development] QML engine C++ class renaming
thiago.macieira at intel.com
Thu Feb 16 15:42:33 CET 2012
On quinta-feira, 16 de fevereiro de 2012 14.56.08, Stephen Kelly wrote:
> On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:
> > On Thursday 16 February 2012 13:39:14 lars.knoll at nokia.com wrote:
> > > Well, it's working for the moment, so the question is where the person
> > > comes from that is willing to keep it alive. Since we'll keep BC after
> > > 5.0, the work would mainly be to adjust to changes in private headers
> > > and
> > > internals.
> > So if one wants to change the private header in qtbase while implementing
> > a
> > new feate, who is responsible to port QtQuick1? The one making the change,
> > or the QtQuick1 maintainers?
> > Because if it is the one making the change, then it becomes a burden for
> > the developers in qtbase.
> Isn't the same true in the QML2 stuff?
Yes, it is more or less the same still.
It's a shared responsibility to fix those issues arising from changing of
internal API. But the point is that there are people to share it with: the one
who made the modification to the internal API in the first place and the person
who understands the code that got broken.
In the absence of either person, it's a nightmare. Which is why I really don't
want a release *at all* unless there's someone to work with when changes to
QtCore do happen. I don't want another ActiveQt on our hands, one that is used
by lots of people and using a lot more internal API.
Also note that there are plenty of strict-aliasing violations pointed out by
the compiler today in the QtDeclarative 4.8 code. It's to be expected that new
versions of GCC *will* cause breakages. Who will fix them?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development