Hi, On Thursday 05 July 2012 08:01:43 Thiago Macieira wrote: > On quinta-feira, 5 de julho de 2012 04.46.22, [email protected] wrote: > > On 05/07/2012, at 2:16 PM, ext Thiago Macieira wrote: > > > There are no plans to write any class to replace QFuture. However, > > > renaming > > > the class right now is close to impossible due to source-compatibility > > > requirements. > > > > What are our source compatibility requirements in regards to modules that > > came from QtMobility? Are there any at this time? Does this even matter, > > really? The blackberry guys would like to add more QSensor's. > > As far as I understand, adding new sensors does not break source or even > binary compatibility. The would break feature freeze at this time, though.
There are two cases: Adding new backend implementations of sensors, which indeed does not change SC or BC, and adding new frontend classes for completely new sensor types, which adds API but does not break SC. It would be nice to get new frontend classes in, otherwise I'll just have to carry those patches to Qt 5.1 and occasionally rebase them. > All modules should be maintaining source compatibility as closely as > possible with Qt 4. I don't know how that instruction has translated to > practical terms for the formerly Mobility modules. I do know that all the > Qt Quick 1 plugins are gone, replaced with QtQuick2 plugins, so there's a > major source compatibility break there. So far the QML side of QtSensors has been the same as in QtMobility.sensor, no compatibility break there. Regards, Thomas -- Thomas McGuire | [email protected] | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
