On Thursday 16 February 2012 21:14:07 Alan Alpert wrote: > On Thu, 16 Feb 2012 20:47:49 ext Olivier Goffart wrote: > > On Thursday 16 February 2012 12:26:50 Alan Alpert wrote: > > > The way QML compatibility is supposed to work is different from C++. > > > Even > > > for a minor version, you don't always just jump to the latest version. > > > Your application continues using the version it was developed for until > > > you choose to update it, deliberately, to a more recent version (note > > > that if the C++ library updates you may get bugfixes transparently, this > > > is primarily about feature additions/changes). > > > > This is a falacy! > > When you upgrade the runtime, you anyway run into compatibility issues. > > The application has been tested to work with the version QtQuick x.y, its > > bug have been work arounded or avoided. > > Now, you come with a new runtime, that pretends to still be load x.y, but > > still fixes bugs? but often, fixing bugs mean also introducing new ones, > > new bugs against which the application has not been tested. And the bugs > > you fix have most likely been work arounded. > > For bugfixes I meant the ones that were safe in this regard. E.g a bug like > "calling foo crashes qml" would get fixed but theoretically, a bug like > "flickable is always 10 too short" would be in a minor version so that you > could remove your +10 at exactly the right time.
So we have two problems here. 1) how do you leave the +10 in QtQuick 2.0 but not in QtQuick 2.1 with the same codebase? you end up with lot of conditional like this? http://paste.kde.org/423326/ Hello maintainence! 2) so when the programmer update its 100+ files application to QtQuick 2.1, he suddenly notice some flickable don't have the right size. How many hours will he take of debugging to find out where to remove that +10 > For introducing bugs, I can assure you that we already try not to do that ;) ;-) (What if you did not change the QmlImage properly in my example? what if you forgot to add the version condition?) > > But why in QtQuick x.(y+1) must I change the import statement. Is there so > > many incompatibilities that will make porting so difficult? > > Probably not. You'll probably change the import statement and it's perfect. > But you can check per application. And consider the two major cases: > > A) Major version change. Let's be honest, you'll be lucky if nothing broke. > This is where there are so many incompatibilities that porting needs to be > taken seriously (even if we try sometimes to keep it from being difficult). For major version change, I totally, agree. > B) Minor version change. This just added some new features. If you don't > need to use the new features, just keep importing the old version and it's > fine. If you do need them, you signify that with an updated import at the > time that you update your code to use new features. Note that because minor > versions can add new features, it will always have the possibility of > adding symbols (suddenly, there's a myObject property on this object and it > shadows the one you were expecting to get from the root object sort of > thing). The problem is that you have a 100+ files application, Are going to mix import statements? > > The versioning in C++ is much better in that respect: > > > > void MyApplication::drawSomething(QPainter *p) { > > #if QT_VERSION >= 0x050100 > > > > p->drawFastTexture(m_texture); > > > > #else > > > > //slow path for old version of Qt > > p->drawPixmap(m_texture.toPixmap()); > > > > #endif > > } > > > > void MyApplication::buttonPressed() { > > #if QT_VERSION >= 0x050100 > > > > if (qVersion() >= 0x050200) { > > > > QAwsomeFeature::run(m_data); > > > > } else { > > > > //workaround the bug in QAwsomeFeature with green nodes > > QAwsomeFeature::run(m_data->removeGreenNodes()); > > > > } > > > > #else > > > > showDialog("sorry, not available with this version of Qt"); > > > > #endif > > } > > > > Then the same source code compiles with different version of Qt and uses > > the newer version of Qt if available. That is usefull for open source > > project for example, where the distribution you target may or may not have > > the newer Qt. > > It will be interesting to see how this works out in practice Well, you don't need to wait. This is all hapenning. Extreme example: you could compile KDevelop 2 with both Qt 2 and Qt 3. And i remember doing it a lot when I was developping for Kopete. > once there > are distros that ship a different version of Qt. I may have seen qt 4.8 in > a fedora somewhere, so this issue is just emerging. QML's approach doesn't > seem as good for supporting multiple Qt versions "at once", but I'm not > convinced that's the common case. (FYI: If you're making the app a QML/C++ > hybrid like you should then you can still use those #ifdefs... but it's > less than ideal.) There is no #ifdefs in QML > > Of course, the inconvinient is that C++ is a static compiled language, and > > then it needs to be compiled. > > > > But with QML you artifitially have this problem because you need to pick > > you version. > > We actually do a lot of that sort of thing in QML. JS is an extremely > dynamic language, Yes, but the "import Quick 2.0" is very static > and we bolt on QML with static types and a frozen global > object. Because some restrictions make life a lot easier. This is one of > them. If you had it left open, sure lots of cases would just work. But > you'd also get the occasional problem which is a real pain in the ass, like > a new symbol being added that shadows a variable name of yours. > Or a behavioral change to an element you weren't expecting. This versioning > scheme attempts to mitigate those risks by making it an opt-in upgrade, > instead of letting the risks fly or (even worse) mitigating them by not > adding new features at this rate. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
