[Development] QML and Qt Quick versioning of our modules

Jason H jhihn at gmx.com
Thu Dec 7 17:06:01 CET 2017


> >1) sync minor versions to Qt release version:
> >For Qt 5.11, we would provide QtQuick.Controls 2.11
> >This way, the challenge for the user is only to find out if it's version 1, 2
> >or 5.
> 
> The "match the Qt version" pattern is used by QtPositioning, QtLocation, Sensors, QtBluetooth and QtNfc too. It gets my support. 
> 
> Coincidentally I forgot to bump all versions for Qt 5.10 :(. Well, my first fixes for 5.10.1

I rather dislike this, unless the 5.10 version are different.
This makes it seem like the code you are using _requires_ that version of module, and that module is different from it's predecessor.  When reading documentation and examples, having a realistic version number is important. Is the demo code workable on my version of Qt? Are you unnecessarily bumping versions? If my Qt is out of date, and I'm trying to use more modern API then it should tell me. But if you're writing code that will work on any version back to Qt 5.8, then that should be the version specified. How do we know 5.8 is the version? Well try it, or have a tool to scan the code and tell you.

Let me ask this, are the versions maintained separately from Qt? If they are, then they should bump, but if they aren't you're just wasting effort. It may be that modules can be maintained separately, but how often is that done? It seems like even Qt 3D is maintained as a proper Qt module, tied to Qt releases. If they want to have inter-release bumps 5.10.x would seem to be the way to go?




More information about the Development mailing list