On Wed, Feb 15, 2012 at 11:17 PM, Alan Alpert <alan.alp...@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 ------------------------------------------------------- _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
