summaryrefslogtreecommitdiffstats
path: root/src/gui
diff options
context:
space:
mode:
authormae <qt-info@nokia.com>2011-02-08 11:33:03 (GMT)
committermae <qt-info@nokia.com>2011-02-08 11:44:15 (GMT)
commitdd49b322b327fe87d8420abcce0e6cee877a88d7 (patch)
tree61a87a94773ca7cc209bcf92967ec5f39bef732a /src/gui
parent77bd529c04b2f08ca40a282a3ff20df699b27295 (diff)
downloadQt-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