Hi, It seems that Jocelyn answered most of the questions, but I put my answers anyway :-)
On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote: > (...) >> 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. Technically it is possible and we should consider to do it if it is _really_ necessary. It is a matter of careful name-spacing in the new major module version. We should not get to a situation in which it is easier to abandon a module and create a new one then bump the major version number. > 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. Enginio is using private API for QObjectPrivate creation. So it has to be re- compiled and tested per Qt patch release. I do not see how it creates dll hell as Enginio is keeping binary compatibility. Each new version is compiled and tested against specific QtCore (and friends) version, it would be 1 to 1 mapping. > 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. From binary compatibility perspective yes, it is a sensible assumption for modules using private api as enginio. From source code perspective it really depends. > 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'. I disagree, then you would end-up with double version numbers which would confuse our users. Is version 1.5 newer then 5.4? How to advocate it? I do not see how 5.x.y.z is different than z.x.y as modules are shipped together with Qt. As far I understand "past mistake" of Enginio is not having "Qt5" prefix, not that it has a different version number. Cheers, Jędrek _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
