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

[Jędrzej Nowacki]

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