On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon <[email protected]> wrote: > Hi, > > > I agree that something "new" needs to be put on the table in order to solve > this. And "this" expands unfortunately to a few issues at the same time. > > > I think that it would be a mistake of "import QtQuick" - without any version > tag - would always import the latest available > version on the system. If we look into other development communities with > package based environments such as Python (pip) > or Go, then we can see that the approach of automatically always importing > the latest version is known to cause more headaches > than do good. Very quickly the users want to be able to _pin_ to a certain > version and be themselves in control when to "upgrade" > to newer API. > > I think that we should learn from this and this is why I think generally > applying a version to the QML APIs is a good thing. I believe that what > we are missing is the convenience of making the conscious step of changing > the of QtQuick 2.4 to 2.5 - it is incredibly tedious at this > point as it requires touching every single file.
I still don't know why people feel they need to do this. Touch the files that you want to use new features in, and if the others are importing a different minor version that's okay. Then the work is only marginally bigger than the actual new feature work in your application. A big point of the QML versioning system is that multiple imports of the same module can co-exist happily in the same engine. > > Therefore I think that we should introduce the notion of configuration files > that apply to an entire project. For QML modules that configuration > file is the qmldir file, although I'd prefer something different. For > applications - the primary target audience in this thread - we are lacking a > central place where we could say that > > > import QtQuick > > > should resolve to exactly version 2.4. > > In other words: I think we should allow application developers to use just > "import QtQuick" in their qml files - without a version. But all that > should mean is that when the engine encounters a version-less import, it > should look for the project configuration file to pick the version the > developer would like to choose. Since we don't have an existing central place for where to look, I think this connection isn't obvious in the code (where it should be easily readable). I like the concept though, maybe it could be "import QtQuick from Project" or "import QtQuick from ../project.qmldir" to give a direct link to the program configuration file. An explicit file link would also help with modules, which presumably need to package their import versions and use them instead of the application settings. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
