[Development] QML engine C++ class renaming

[Artur Souza (MoRpHeUz)]

On Wed, Feb 15, 2012 at 11:17 PM, Alan Alpert <alan.alpert at nokia.com> wrote:
>
> Now the fact that the C++ APIs are being maintained as well, and in this
> somewhat drastic manner, for an obsolete major version... it's not the ideal
> case that QML versioning planned for. So we'll see how effective this approach
> is. But the ideal that we're aiming for is with QML versioning is that you
> choose to upgrade at an application level after the library version goes up,
> instead of being forced into breakage. That requires something like QtQuick
> 1.0 sticking around for a while. Hopefully the next major version won't need
> so drastic a rewrite.

IMHO the big problem here is the maintenance cost of QtQuick1 as
Thiago pointed out.

The internals are different enough from QtQuick2 that we may not give
it enough attention/work. And then we may have the same situation as
we had with qt3support: people using it and we wanting them to come to
the new code.

As d3fault pointed out in his email, but the end of Qt5 we will have
much more people using QtQuick1 than we have now, because this is the
time they are *starting* to use QML.

Maybe, as QML is young enough, the better strategy would be to just
stick with it's newer version.

PS: I agree that it would be fantastic to have a backward compatible
module, I'm just trying to be honest with myself and realize that the
chances that it will not be properly maintained are huge :)

-- 
-------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
-------------------------------------------------------
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------