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

[Jędrzej Nowacki]

On Monday 30 of June 2014 10:06:12 Olivier Goffart wrote:
> 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.

Hi, 

  As I agree in principle I do not think it is feasible in all cases. There 
are few problems:

 1. Lack of public api
 1.1 We have private api that could be polished and promoted to public, that 
could be done of course it is a bit of effort but it make sense.
 1.2 Private api that make sense only to an internal use-case, does it make 
sense to generalize it and potentially make everything more complex, 
especially in context of long term BC?

 2 Performance, public api is generally slower then a private one, because of  
inline'ing, type checks, range checks and so on.


What about creating an intermodule api, which would stay private from a user 
point of view. We can agree on some rules, like for example not removing 
symbols between patch releases, having some test coverage?

Cheers,
  Jędrek