[Development] Proposal: All Qt modules must use the same version number

[Jocelyn Turcotte]

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