Re: [Development] binary compatibility promise
On 23 Nov 2012, at 11:20, Peter Hartmann phartm...@rim.com wrote: On 11/23/2012 11:11 AM, Poenitz Andre wrote: 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? yes, e.g. device updates and 3rd party apps in the store. Well, even for device updates 3rd party apps, the most sensible thing IMO is to provide a beta period for the device update to 3rd party app developers, so they can test their applications against the new versions and possibly update their application in the store. I mean there *are* behavior changes in every new version of Qt, also patch releases, that's what bugfixing is about ;). That might affect one or the other application in a negative way, in addition to the one or other bug that unfortunately gets introduced. Regarding can you run an application that was compiled against x.y.z also with x.y.(z-1), I think that is simply a question of defining a policy. Also for shared Qt versions on devices, it is just a policy against which Qt version applications should be compiled to run on the wanted number of device installations. -- 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 phartm...@rim.com: 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
Re: [Development] binary compatibility promise
-Original Message- [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Ziller Eike On 23 Nov 2012, at 11:20, Peter Hartmann phartm...@rim.com wrote: Do you intend to upgrade this version of Qt that's installed on the device without upgrading the applications using it? yes, e.g. device updates and 3rd party apps in the store. Well, even for device updates 3rd party apps, the most sensible thing IMO is to provide a beta period for the device update to 3rd party app developers, so they can test their applications against the new versions and possibly update their application in the store. I mean there *are* behavior changes in every new version of Qt, also patch releases, that's what bugfixing is about ;). That might affect one or the other application in a negative way, in addition to the one or other bug that unfortunately gets introduced. Regarding can you run an application that was compiled against x.y.z also with x.y.(z-1), I think that is simply a question of defining a policy. Also for shared Qt versions on devices, it is just a policy against which Qt version applications should be compiled to run on the wanted number of device installations. I *think* the plan is: - there will be a single version of Qt 4.8.x shared by all apps on the device. - that single version may be upgraded by RIM at some time (ie 4.8.y, doubtfully 4.9.z, not Qt5) - there would be extensive in-house testing of the upgrade, including testing with a wide array of 3rd party apps - Apps downloaded from AppWorld would not / could not upgrade the global installed Qt - (apps can always ship their own captive version of Qt if they want, but that tends to just waste space) Eventually there should be a 5.x version of Qt, but that would be with a major platform upgrade - breaking BC not just with Qt, but with the BB libs, and at which time both 4.8.x and 5.x would co-exist on the device (as well as coexisting versions of BB libs). CAVEAT: I'm not in charge of this, and things can and do always change, but I think that's the general plan Does that make sense to everyone? Tony - 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
[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
On 11/23/2012 11:11 AM, Poenitz Andre wrote: 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? yes, e.g. device updates and 3rd party apps in the store. Peter Andre' - 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
