summaryrefslogtreecommitdiffstats
path: root/LICENSE.PREVIEW.COMMERCIAL
diff options
context:
space:
mode:
authormae <qt-info@nokia.com>2011-02-08 11:33:03 (GMT)
committerJason McDonald <jason.mcdonald@nokia.com>2011-02-09 07:14:49 (GMT)
commit70cacb48b0bdbfe6ca58b7472cbeadb18d4dfc35 (patch)
treee10df83ef93e8403e77b1bb5b4fc417804c9e830 /LICENSE.PREVIEW.COMMERCIAL
parenta7b953fb6f246f3d61723872ac97a1721fece128 (diff)
downloadQt-70cacb48b0bdbfe6ca58b7472cbeadb18d4dfc35.zip
Qt-70cacb48b0bdbfe6ca58b7472cbeadb18d4dfc35.tar.gz
Qt-70cacb48b0bdbfe6ca58b7472cbeadb18d4dfc35.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 (cherry picked from commit dd49b322b327fe87d8420abcce0e6cee877a88d7)
Diffstat (limited to 'LICENSE.PREVIEW.COMMERCIAL')
0 files changed, 0 insertions, 0 deletions