[Development] binary compatibility promise (was: Re: Frameworks on Mac?)
On 11/23/2012 12:12 AM, André Pönitz wrote: > (...) > The reality is that this guarantee often enough does not hold in > practice. Vendors of "binary" Qt based application typically test their > setup against one specific (often enough patched) version of Qt which > is then shipped with the application. Users are not expected to switch > Qt versions, except when upgrading the whole application. Insofar are > rules like "we can't add symbols in patch releases" not much more then > self-inflicted pain without measurable gain. This situation is different on mobile (and I guess embedded as well); for BlackBerry10 we have one version of Qt on the device and often cross-compile apps with another version of Qt; so we depend on the binary compatibility promise for patch releases (and in fact were bitten by the new symbols as well when people reported their app was not launching with "unknown symbol: _ZNK20QFutureInterfaceBase4refTEv" etc.). Peter > >> Isn't it true that duplicate copies of Qt in every application will >> result in duplicate copies being loaded into RAM too? > > Better double memory consumption then unexpected behaviour changes. > > Andre' > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)
Peter Hartmann wrote: > On 11/23/2012 12:12 AM, André Pönitz wrote: > > (...) > > The reality is that this guarantee often enough does not hold in > > practice. Vendors of "binary" Qt based application typically test their > > setup against one specific (often enough patched) version of Qt which > > is then shipped with the application. Users are not expected to switch > > Qt versions, except when upgrading the whole application. Insofar are > > rules like "we can't add symbols in patch releases" not much more then > > self-inflicted pain without measurable gain. > > This situation is different on mobile (and I guess embedded as well); > for BlackBerry10 we have one version of Qt on the device Do you intend to upgrade this version of Qt that's installed on the device without upgrading the applications using it? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)
On 23 Nov 2012, at 11:07 AM, Peter Hartmann wrote: > On 11/23/2012 12:12 AM, André Pönitz wrote: >> (...) >> The reality is that this guarantee often enough does not hold in >> practice. Vendors of "binary" Qt based application typically test their >> setup against one specific (often enough patched) version of Qt which >> is then shipped with the application. Users are not expected to switch >> Qt versions, except when upgrading the whole application. Insofar are >> rules like "we can't add symbols in patch releases" not much more then >> self-inflicted pain without measurable gain. > > This situation is different on mobile (and I guess embedded as well); > for BlackBerry10 we have one version of Qt on the device and often > cross-compile apps with another version of Qt; so we depend on the > binary compatibility promise for patch releases (and in fact were bitten > by the new symbols as well when people reported their app was not > launching with "unknown symbol: _ZNK20QFutureInterfaceBase4refTEv" etc.). I think that is also the reason Necessitas distributes Qt as separate packages, with apps depending on it, so that it can be shared between apps, right? If vendors really need to redistribute Qt with every app on Mac and Windows, they could at least link it statically so that unused functions can be omitted. But apparently there are problems with that too. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)
On 23 Nov 2012, at 14:15, Rutledge Shawn wrote: > > On 23 Nov 2012, at 11:07 AM, Peter Hartmann wrote: > >> On 11/23/2012 12:12 AM, André Pönitz wrote: >>> (...) >>> The reality is that this guarantee often enough does not hold in >>> practice. Vendors of "binary" Qt based application typically test their >>> setup against one specific (often enough patched) version of Qt which >>> is then shipped with the application. Users are not expected to switch >>> Qt versions, except when upgrading the whole application. Insofar are >>> rules like "we can't add symbols in patch releases" not much more then >>> self-inflicted pain without measurable gain. >> >> This situation is different on mobile (and I guess embedded as well); >> for BlackBerry10 we have one version of Qt on the device and often >> cross-compile apps with another version of Qt; so we depend on the >> binary compatibility promise for patch releases (and in fact were bitten >> by the new symbols as well when people reported their app was not >> launching with "unknown symbol: _ZNK20QFutureInterfaceBase4refTEv" etc.). > > I think that is also the reason Necessitas distributes Qt as separate > packages, with apps depending on it, so that it can be shared between apps, > right? If installing one application can upgrade the Qt version (i.e. including removing the older Qt version) that is then used by all Qt apps, that sounds really scary to me. At least that requires application developers to continually track which Qt version might get installed (i.e. when that shared Qt installer is updated), and check their application with it. > If vendors really need to redistribute Qt with every app on Mac and Windows, > they could at least link it statically so that unused functions can be > omitted. But apparently there are problems with that too. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)
23.11.2012, 14:07, "Peter Hartmann" : > This situation is different on mobile (and I guess embedded as well); On embedded you usually can rebuild all software when changing Qt, so binary compatibility is not important. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
