On 10/04/2010 01:17 AM, [email protected] wrote:
Hi
Alex branched 1.1 QtMobility today, so the 'master' branch of the
mobility repo will contain the workings of QtMobility 1.2, which will
add support for Meego.
http://qt.gitorious.com/qt-mobility/qt-mobility
QtMobility 1.2 is targeted for MeeGo 1.2.
From the packaging point of view, we'll skip 1.1.x and
upcoming Trunk packages will based on master branch.
QtMobility packages based on master branch are ready in our staging area.
These packages requires QMF 2010w36. Please be advised, several renaming
changes have been made to QMF. These changes are unfortunately source and
binary incompatible and will require software dependent on QMF to be updated.
Please see below for details:
- libmessageserver -> libqmfmessageserver
- libqtopiamail -> libqmfclient
- qtopiamailfile -> qmfstoragemanager
These changes are illustrated in this commit:
http://qt.gitorious.org/qt-labs/messagingframework/commit/d3640202abeced192a89ec57b90fdb30e1aa551b
From a MeeGo packaging point of view:
pkgconfig(qtopiamail) -> pkgconfig(qmfclient)
So... if I'm reading this correct then we are skipping past the entire
mobility 1.1 stabilization and immediately pushing the bleeding edge
work which will eventually become mobility 1.2?
I fear that this is going to cause havoc on application development
process if we see constant breakage on a very critical set of API's.
How about we push in the mobility 1.1 beta into Trunk, followed by
beta?/rc?/final-release, and then hold off on pushing in 1.2 till the
code is a bit further along (like the first technical preview or beta
release?)
Perhaps host a sandbox for the cutting edge
mobility-1.2-hasn't-hit-tp-yet for those that really need it?
--rusty
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
