[Development] QML engine C++ class renaming

[Thiago Macieira]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120216/16a37c8b/attachment.sig>