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

[Olivier Goffart]

On Sunday 29 June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote:
> No if it uses private headers.
> 
> I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5 each
> time I upload a new point release for this exact problem [0]. I would really
> like to avoid adding new stuff to that list, as it is a real PITA.
> 
> [0] Even if API/ABI matches, there seems to be a runtime detection of
> different versions of Qt in qobjectprivate. I can really understand why that
> check is there, so the best solution is to avoid "third party" stuff to use
> private headers. Having a different release schedule will certainly make
> any package count as "third party" in my POV.

Totally off topic: I think using private header should be tried to be avoided. 
In the past, we used private header inside Qt because Qt was not split that 
much.  But one of the goal of modularisation was to allow independent release 
of different component of Qt.  The problem is that we could not get rid of the 
private header dependencies at the time (too much work).
But still now, every module, even new, are using the private headers. Nothing 
is done to try to prevent it.

I think there should be some kind of long term goal to avoid using private 
headers. 

We need to find a solution so that one need not to inherit from 
QObjectPrivate. (There is already QObject::setUserData, but it could be done 
better i guess)

We need also to identify private APIs that could be polished and made public.
For some modules such as QtQuick this is probably too hard.
But for new modules such as WebEngine or such, it may be possible to avoid 
dependency on private API.


-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org