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

[Stephen Kelly]

Hello,

At QtCS I briefly discussed with Lars my proposal to make a 'fixed' release of 
qtenginio:

 http://thread.gmane.org/gmane.comp.lib.qt.devel/17144/focus=17272

He did not accept it because situations could arise where a downstream 
accidentally loads both libraries (eg through 3rd party transitive 
dependencies) with the old and new SONAMES, and cause segfaults. 

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. 

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

----

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.

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.

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

Thanks,

-- 
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com

Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions