Hello everyone! Here's some background information about when we might release updates for SyncEvolution. This isn't set in stone; think of it more like the grand master plan that we strive for... and then change after impact with the real world ;-) Scheduling is driven by "release when ready" and "we want regular updates at a deterministic point in time", so let's look at the feature list first: The high-level goals for 0.9.1 are: * bug fixing, including string changes that we had to postpone in 0.9 * include message resend (merged, found problems in testing) * revised backend API (merged, no regressions so far) * mobical.net interoperability * Memotoo interoperability (because of user demand)? * stretch goal: revised D-Bus API Message resending was merged, but then a thorough testing against Funambol and ScheduleWorld showed that there is one particular case where the sync hangs when a certain message reply gets lost. This looks like a server bug. With the Synthesis server it works. The high-level goals for 1.0 are: * implement revised D-Bus API and architecture (support Genesis GUI; syncevolution as D-Bus client) * performance and reliability improvements (EDS API) * minimal support in sync-ui for SyncML server mode * stretch goal: implement the intended SyncML client design in sync-ui (current one is lacking recovery features, progress spinner, etc.) * stretch goal: OBEX support for SyncML client and server * SyncML server mode (peers to be decided) In particular the last item has a huge tail of detailed testing work associated with each peer. For 1.0, our goal has to be to get the infrastructure in place and prove that it works with a few phones. We probably could work this forever. At the same time we want to get another stable release out the door so that we can ship the other improvements. The biggest unknown factor for 1.0 are the necessary changes in libsynthesis. Lukas has reassured me that he has made good progress towards those, but they have a business to run and therefore might have more important work to deal with first. September 4th in the schedule below is way too early - more realistic proposals welcome ;-} With that in mind, here are some milestones that could get us towards 1.0, with names attached to the major tasks and until when they need to be done to stay on track: * Jussi, Patrick, August 26: decide about D-Bus server-side technology - done, let's use libdbus + gdbus + custom C++ binding * Patrick, August 28: core server engine and complete C++ binding - much of that is done. * Jussi, August 28: D-Bus GUI API redefined, with feedback by others - still a bit of work needed * Patrick, Yongsheng, September 11: new D-Bus API implemented (must work incrementally, so that Jussi can adapt the GUI in parallel) * Synthesis, September 4 (?): SyncML server API discussed and usable * Jussi + Patrick + Nick, September 9+10: face-to-face in London, discuss design issues * Congwu, September 4: EDS API enhancements + usage of those in SyncEvolution backends - patches ready for review, Ross will do that for EDS, Patrick for SyncEvolution * Congwu, September 11: outgoing OBEX connections with transport inside SyncEvolution * Patrick, September 18: Synthesis server feature integrated into SyncEvolution * all, end of September: first alpha * all, end of October: final release We have to be aware that we have to leave enough gaps in the schedule for unexpected problems or requests and the "optional" open issues (see attachment). I consider some of these important that I don't want to push them out forever: * code cleanup * revive SQLite demo backend and perhaps Mac OS X and Maemo support (although I really hope that the later two will be covered by external developers) * split data transformation part out of libsynthesis -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.