> I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to general > Qt releases. There were quite some constraints and added flexibility was nice. > Qt Quick has matured a lot though, so I think it's time to consider making > everyone's lives easier by cleaning up our version chaos. > See also J-P's previous mail here: http://lists.qt-project.org/pipermail/ > development/2015-September/023200.html
As a user I've been very confused about what this (stated versions) is and why I need it. If I could draw some parallels with node, they have a package.json file which specifies versions for modules with a decorator to identify valid versions. ( https://docs.npmjs.com/misc/semver ) Meanwhile the source files just spend characters importing the module. I originally thought that specified version was specifying the minimum version, however this is not true in practice. Many times the version is just specified as the current. And what happens with a project that specifies multiple versions in multiple import statements? In the vein of "if you say something that isn't right, it's wrong" the version numbers are nothing but wasted characters full of wrong information. So they should be eliminated. If versions are to be specified, they should: 0. Indicate the minimum version required, or acceptable versions, by the spec. 1. Be implicitly determined by the API in use, and not the responsibility of the developer 2. Be maintained in _one_ place Therefore, it seems appropriate to adopt the package.json for QML. And maybe it's already a thing with qpm? ( https://www.qpm.io/ ) _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
