On Wed, 15 Feb 2012 21:41:06 ext Artur Souza (MoRpHeUz) wrote: > On Wed, Feb 15, 2012 at 8:31 AM, Olivier Goffart <oliv...@woboq.com> wrote: > > Anyway, this is a compatibility library. It's sole role is to be there to > > help transition (just like qt3support was) > > I had the impression that most people agreed that qt3support was a > mistake. Are we going to take the same strategy for Qt5? :)
There is an important difference here, which is that we're looking at QML APIs instead of C++ APIs. The way the QML versioning system is meant to work is that you have multiple versions of your QML module in the one library/plugin and pick out the right one using an import statement. This is different from the C++ library approach of having one version which is forwards and backwards compatible. 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. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development