Hello, At QtCS I briefly discussed with Lars my proposal to make a 'fixed' release of qtenginio:
http://thread.gmane.org/gmane.comp.lib.qt.devel/17144/focus=17272 He did not accept it because situations could arise where a downstream accidentally loads both libraries (eg through 3rd party transitive dependencies) with the old and new SONAMES, and cause segfaults. This is of course the same situation that could arise if linking a program with both Qt4Core and Qt5Core or anything. The problem is that we have this problem within the lifetime of Qt 5. Conclusion 1) Even if a Qt module has a disparate version scheme, bumping its major version and changing its SONAME are not acceptable. Therefore the major version must stay the same until Qt 6. Proposal 1) All Qt modules must use the major version '5' for consistency. ---- qtenginio uses private QtCore API. $ git grep "\-private" src/ src/enginio_client/enginio_client.pro:QT += core-private network src/enginio_plugin/enginio_plugin.pro:QT += qml quick enginio enginio-private core-private That means that a particular version of qtenginio is tied to a particular version of QtCore. Conclusion 2) A disparate version scheme for something released 'as part of Qt 5.x.y' creates dll-hell. Furthermore, the version of qtenginio released with Qt 5.x.y is only tested with that 'distribution version' it was part of (that is qtenginio 1.0.5 was only tested with and a part of Qt 5.3.0). There is no way anyone is going to test any significant portion of the possible combination matrix. Conclusion 3) Using the version of qtenginio released with the version of Qt it was distributed with is the only sane thing to do. A requirement to make newer releases of qtenginio work with previous Qt releases would constrain qtenginio development. Conclusion 4) If multiple qtenginio releases are made between Qt 5.x.y and Qt 5.x.y+1, they can only reasonably be expected to work with Qt 5.x.y, not later or earlier releases. Proposal 2) All modules which are 'part of Qt 5.x.y' must use the version number '5.x.y'. If a module wants to make an out-of-band release, they must use a different version number such as 5.x.y.z or some other completely different number (1.0.5 would also be ok for an out of band release, but that could not be part of Qt 5.x.y). qtenginio is exempt from these proposals because it is a 'past mistake'. Thanks, -- Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com Stephen Kelly <[email protected]> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
