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

[Jędrzej Nowacki]

On Monday 30 of June 2014 09:48:05 Stephen Kelly wrote:
> On Friday, June 27, 2014 14:50:39 you wrote:
> > 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.
> 
> Can you give us some criteria for 'really necessary' which are not met by
> the enginio situation?
Well, it is exactly the same as breaking any other BC promise. Breaking BC 
just to satisfy SONAME naming convention is not really convincing me. If we 
have to change api and architecture of the module, then we may consider 
bumping the major version. By "really necessary" I meant that the operation 
should be avoided, and we should try to keep BC as long as possible.

> > 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.
> 
> Then what is the real value in the major version number being different?
>From a user perspective it it different and from technical perspective you can 
keep the same module and class names.

> > 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.
> 
> Version 1.0.5 works with Qt 5.3.0. Version 1.0.7 may not work with any
> 5.3.x.
> 
> Given that qmake has no way of helping you out with that, do you really not
> see a problem?
Not really as Qt5.3.x version would be shipped with specific version of 
Enginio, from qmake perspective there should be only one Enginio library. 

> > Each new version is compiled and tested against specific QtCore (and
> > friends) version, it would be 1 to 1 mapping.
> 
> Such a mapping would exist only in brains or in a wiki page.
> 
> Why create a situation where such a mapping is needed at all?
Why? By default we install all submodules so the mapping would be implicit the 
installer.

> > > 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?
> 
> Good questions.
> 
> Is qtenginio 1.0.7 newer than Qt 5.4? How to advocate it?
> 
> Why get into a situation where such questions need to be asked at all?
If Enginio 1.0.7 is shipped with Qt5.4 then the question is invalid from a 
user point of view, because Enginio is installed already, Whatever it is the 
newest possible one or not is a different story, solved by maintenance tool.

> > As far I understand "past mistake" of Enginio is not having "Qt5" prefix,
> > not that it has a different version number.
> 
> We definitely made multiple mistakes there. At least not discussing the
> break from convention was another one.
Well, it was not a break really. QtWebkit, when it was heavily developed was 
released on own schedule, with an additional version number. Then one of the 
goals of modularization, around five years ago, was to be able to release a 
module on their own. I wrongly assumed that it is a common knowledge, I'm 
sorry for that.  

> Thanks,
Cheers,
  Jędrek