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

[Stephen Kelly]

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?

> 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?

> 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?

> 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?

> > 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?

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

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