On Sun, Dec 16, 2012 at 4:02 AM, Attila Csipa <[email protected]> wrote: > I don't necessarily care how different a shiny new API implementation is and > if the fact that my application runs on it is purely coincidental based on > how I use those APIs, but not having a way to say "YES, I know you bumped an > API version, YES, I know there are potential incompatibilities, and YES, I > tested it, and YES, it still works" is super-frustrating.
There's no way to say that because you don't need to say anything in that case. If we bump the minor version and it still works (because you aren't needing any of the new features) then it will still work without you even having to alter your QML code to bump the version you import. Would the following change help, if import Module x.y chose the highest minor version available? So you import QtQuick 1.9, and it will fall back to QtQuick 1.1 or 1.0, depending on which is available on the system. This sort of functionality is what I think you're asking for. Turns out that system is inferior to the current one, because it has more developer effort for worse effects. You'd either bump the minor version all the time, for the same effect as the current system, or you'd use a large number to 'automatically' update and risk breaking (because obviously you haven't tested against QtQuick 1.9 yet). If you aren't using the new API then the lower minor import continues to work, and if you are using the new API then the lower minor import cannot work. Note that the way the versioning system is implemented it is easy (and strongly encouraged) to provide all minor versions of the module in the package for that major version. So anywhere that supports QtQuick 1.1 should also support previous minor versions, like QtQuick 1.0. That isn't strictly enforced by the engine, but should be enforced by convention and the engine deliberately makes that case easy. As for major versions, those are expected to be wildly different and developers need to make a choice of major version explicitly, so not being able to run the same code between QtQuick 1.x and QtQuick 2.x is expected. It's like how you have to compile against Qt4 or Qt5, you can't run the same binary against both (but because QML is an interpreted language, the choice has to be made at runtime based on the import statements). Eventually people will stop shipping Qt 4 and then you'll need to provide your own if you want to keep running a Qt4 app - same with QtQuick 1. If the problem is that QtQuick 2 (or Qt 5 for that matter) looks so close that you thinks you *should* be able to run the same code with the previous version, then you should be disputing the choice to increment the major version instead of the minor version. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
