On Fri, Jun 27, 2014 at 11:28:14AM +0000, Koehne Kai wrote: > > > > -----Original Message----- From: > > [email protected] [...] 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' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
