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

[Thiago Macieira]

Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
> 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.

Why is it not acceptable?

> Proposal 1) All Qt modules must use the major version '5' for consistency.

There's a difference between "this is a Qt 5 library" and "this is a Qt library 
with version 5". We agreed to hardcode QtCore's version number in every 
library, not to force every library version to 5.

> 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.

The big problem here is that Enginio, like every other Qt module, uses the Qt 
.prf files from qtbase, which do not maintain forwards or backwards 
compatibility. Trying to compile older versions of a given module with a newer 
Qt usually causes trouble.

But mind you that we have to fix that anyway, since we have modules frozen in 
time: qthttp, qtftp, qtstyleplugins.

> Proposal 2) All modules which are 'part of Qt 5.x.y' must use the version
> number '5.x.y'.

I disagree. We might end up doing that, but it shouldn't be forced.

> 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'.

Enginio should be allowed to keep its version number as it is.

New modules should be allowed to choose their numbering. We'd have 
libQt5Foo.so.1.0.0, for example.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center