On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote: > My two cents as a user of these APIs: having to deal with a major API > change once is acceptable. Whether it is in 3.2 or 3.4 I don't really > care. > > But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So > if the account handling doesn't land in 3.2, then please let's keep the > current (EDS 3.0) APIs officially supported in 3.2.
There are no major (nor minor, that I'm aware of) public API breaks in 3.1 as of yet, just new alternative APIs for EBook and ECal. EBook and ECal are deprecated but still work the same, and will remain until we've verified all known users of the APIs have migrated. I would suggest staying with EBook and ECal until the account management changes land. I'm trying my best to get that done by 3.2, but there are inevitable APIs breaks that will accompany it regardless of when it lands. Half of libedataserver will be thrown out and replaced, with moderate impacts to libedataserverui, libebook and libecal. If you're interested yet, documentation for the new libedataserver API is posted here. I do plan to write a migration guide before merging. http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/index.html I also wrote about impacts to the other libraries awhile back. It's slightly dated and incomplete now, but what's there is still accurate: http://mail.gnome.org/archives/evolution-hackers/2010-December/msg00029.html _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers