status 2010-11-17: old-style config regression in SyncEvolution 1.1, phones, additional protocols

[Patrick Ohly]

Hello!

It has been a while that I posted a project update. Time to change
that...

SyncEvolution 1.1 is in fairly good shape. It seems that releasing it
caused some people to upgrade or try it out who had not seen the
previous betas, which has led to some bug reports. Keep them coming!

One regression affects users upgrading from SyncEvolution <1.0
(http://bugs.meego.com/show_bug.cgi?id=9381). Fix will be in 1.1.1,
workaround is this:
      * remove the ~/.config/syncevolution/<config name>/peers directory
      * run "syncevolution --migrate <config name>"

Several issues with phones were reported:

        Sony Ericsson t700 crashes with VALARM section in .ics
        http://bugs.meego.com/show_bug.cgi?id=10091
        
        slow sync + conflict resolution + duplicates
        http://bugs.meego.com/show_bug.cgi?id=10081

        Nokia phones (N97): *updated* calendar events not accepted by
        phone
        http://bugs.meego.com/show_bug.cgi?id=9600

        Sony Ericsson doesnt handle repeat-rule: until in vevent
        http://bugs.meego.com/show_bug.cgi?id=10092
        
        Sony Ericsson C510: need workaround for SyncML violation
        [mailing list]

I considered releasing a 1.1.1 with just the regression above fixed, but
because of the other reports I'll probably wait a bit until some of
these are addressed.

My main focus right now is on support for additional, non-SyncML
protocols. I like to call this "local sync" because it synchronizes data
provided by two local SyncEvolution backends. The data itself can be
anywhere. I have this in a usable state, see bmc712-local-sync branch.

I'm testing this new feature with a backend which, unfortunately, at
this time is closed-source. I'm confident that this will change in 2011.
        
-- 
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.