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

[André Pönitz]

On Fri, Jun 27, 2014 at 11:28:14AM +0000, Koehne Kai wrote:
> 
> 
> > -----Original Message----- From:
> > development-bounces+kai.koehne=digia.com at qt-project.org [...] We'll
> > always have a 1-to-1 mapping of QtWebEngine and Qt versions and we'll
> > always distribute/test them together. If we release QtWebEngine 1.u.v
> > with Qt 5.x.y, then QtWebEngine 1.u+1.v will also depend on Qt 5.x.y.
> >
> > The two advantages that this gives us is that we can release
> > QtWebEngine more often than Qt, if we want to, and that we can have a
> > version number that reflects our maturity and not the maturity of Qt as
> > a whole.
> 
> My 2 cents from the packaging/installer side: Any artifact that is
> heavily bound to a specific Qt build / release, but isn't part of the Qt
> package itself, is making things complicated. 
> 
> One example: We used to have the Qt packages split up into 'essentials'
> and 'addons' ... only that Qt Assistant, as part of 'essentials', did
> depend on the 'addon' QtWebKit, and didn't start if QtWebKit was missing.
> In practice, we got almost no complains about this, which probably means
> that nobody bothered to install essentials without addons, in the first
> place :) As a result we're nowadays shipping one Qt binary package,
> including all prebuilt essentials & addons together.
> 
> I'm not sure whether this exact problem will be an issue with QtWebEngine
> too, or for how long Qt Assistant will continue to use QtWebKit. But
> keeping interdependent packages in sync is certainly not a free ride.
> 
> That's of course only the binary installer ... I can't judge whether e.g.
> distributions would appreciate separate releases of QtWebEngine. But
> given that we're planning to hand out Qt patch level releases more often
> I'd like to lobby for KISS in this case. That is, if it's an integral
> part of Qt, shares the BC promises of Qt, ... I think it should share the
> version number, too.

This pretty much sounds like "If a module uses private API it should
follow Qt Core numbering, if it doesn't it's free to pick anything."

Andre'