[Development] QML engine C++ class renaming

[Olivier Goffart]

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.

But why in QtQuick x.(y+1) must I change the import statement. Is there so 
many incompatibilities that will make porting so difficult?

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.

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.

> Considering the amount of
> effort it could take to port your QtQuick 1.0 application to QtQuick 2.0,
> I'd think QML users would be really happy to have this sort of grace period
> where both will work; even if it's of indeterminate length.

That, I agree with.
(we are talking about major release changes)