The following should fail:
while the following should succeed
We also need versioning for other things exposed to QML – signals, slots, and Q_INVOKABLEs.
QML is slightly different to C++. In C++ adding a new method or property cannot break old applications, whereas in QML as an object's properties can appear in a scope chain it can change what a name resolves to.
For example, consider these two QML files
where CppItem maps to the C++ class QCppItem. If, in a new version of their module, the author of QCppItem adds a "root" property to QCppItem it will break my program. Our solution is to allow the author of QCppItem to say that the new root property is in revision 2 of QCppItem and QML will make sure that it is only accessible if you "import MyModule 1.1". In this way we can permit new properties and features to be added to existing QML elements while not breaking existing programs.
This is important for QML itself. QML is currently tied to Qt releases via the import Qt 4.7 module. In order to allow progress in the QML core elements we must decouple the QML elements from minor Qt releases. This allows us to react to stakeholder requirements and address our oversights in a reasonable timeframe. Once the enablers are in place, the QML core elements should have their own module name. The current proposal is to use import QtQuick 1.0 starting with Qt 4.7.1. Note that import Qt 4.7 will continue to work.
This will also be needed for other modules such as Qt Components and Qt Mobility. Since these are based on Qt 4.7 we must ensure that this is available in Qt 4.7.1.