Hello, we're soon going through this process with QtWebEngine, so let's use this as a concrete example. We can possibly use this as a guideline for future Qt module as well.
We already went through some discussion, and I'll share our plan here, but nothing is set in stone so let's see if we need to change that plan and why we would need to do it. We want to name our first release 1.0 (libQt5WebEngine.so.1.0.0) which would depend on libQt5*.so.5.4.0. We use private API, so: - We need to only distribute QtWebEngine together with Qt, you can't download QtWebEngine 1.0 that would work with both QtCore 5.4 and 5.5 - We have to bump our minor/patch version for each new minor/patch release of Qt, even if nothing changed in QtWebEngine, since we will eventually have #ifdefs to switch from one Qt private API to the other and our list of imported dynamic symbols will change. That means that the same code wouldn't produce the same binary if build with two versions of Qt even if they use the same configuration. On a side note unrelated to QtWebEngine, I think that if if a module only depends on public API of other modules, binary compabitility should allow both versions to move freely, given that a minimum version is required for each dependency module. They behave the same as any external library depending on Qt and I don't see a reason for them to use the same version number. On Wed, Jun 25, 2014 at 03:42:36PM +0200, 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. When we switch to Qt 6 we'll also bump QtWebEngine to 2. QtWebEngine1 depends on Qt5 and QtWebEngine2 depends on Qt6. > 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. > ... > 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. We'll always have a 1-to-1 mapping of QtWebEngine and Qt versions and we'll always distribute/test them together. If we release QtWebEngine 1.u.v with Qt 5.x.y, then QtWebEngine 1.u+1.v will also depend on Qt 5.x.y. The two advantages that this gives us is that we can release QtWebEngine more often than Qt, if we want to, and that we can have a version number that reflects our maturity and not the maturity of Qt as a whole. Those are not very important advantages and we can give them away if you guys think that we should stick to the Qt version number, but I'll let you debate over that part. On the other hand, I think that our plan addresses all the issues that you raised, so le me know if there is anything that we're overseeing, Cheers, Jocelyn _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
