diff options
author | mae <qt-info@nokia.com> | 2011-02-08 11:33:03 (GMT) |
---|---|---|
committer | mae <qt-info@nokia.com> | 2011-02-08 11:44:15 (GMT) |
commit | dd49b322b327fe87d8420abcce0e6cee877a88d7 (patch) | |
tree | 61a87a94773ca7cc209bcf92967ec5f39bef732a /src/gui | |
parent | 77bd529c04b2f08ca40a282a3ff20df699b27295 (diff) | |
download | Qt-dd49b322b327fe87d8420abcce0e6cee877a88d7.zip Qt-dd49b322b327fe87d8420abcce0e6cee877a88d7.tar.gz Qt-dd49b322b327fe87d8420abcce0e6cee877a88d7.tar.bz2 |
Support seperate versions of installed modules
QML supports versioned types in modules. There's a version major and a
version minor.
This makes it possible to have a module com.organisation.fancycomponents
with version 1.0, and later you could ship a new module
com.organisation.fancycomponents which contains a more recent version 1.1
or 2.0 AND also the old versions to keep old code running.
This is good.
The problem is that this is difficult with certain QA procedures. It's
hard to verify that a new module is indeed 100% compatible with the
previous versions.
The change extends the import mechanism by adding optional versioning to
the component patch.
With the patch, you can add a new module
com.organisation.fancycomponents.2.0 which will be loaded when the
QML file specifies "import com.organisation.fancycomponents 2.0".
The patch works as follows: if you try to load
com.organisation.fancycomponents in version 2.0, the engine first
looks for com/organisation/fancycomponents.2.0, then for
com/organisation/fancycomponents.2 then for
com.organisation/fancycomponents.
Reviewed-by: Aaron Kennedy
Task-number: QTBUG-16455
Diffstat (limited to 'src/gui')
0 files changed, 0 insertions, 0 deletions