>-----Original Message----- >From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On >Behalf Of ext Rusty Lynch >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?
In principle I kind of agree with Rusty but the practical implications may ruin this. The Mobility 1.2/master branch is going to be open battleground and regressions are to be expected. Where I see the problem is on the backend side of things. A lot of our Mobility API's will only get their Meego backend during the Mobility 1.2 development phase. Hence a push of 1.1 libraries may bring the API to Meego but the backend may not exist yet. The question becomes what is more important. Having the library/API early without a potential backend or having only those libraries which work already (the ones kind of working already are: Bearer, SFW, Sensors, Messaging, Versit - biggest gap would be Positioning, Contacts, Organizer) In any case QMF should not be a problem. Mobility 1.1 and 1.2 use the new QMF headers already. -- Alex _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
