On Mon, 2011-05-23 at 11:54 +0200, Milan Crha wrote: > I just committed changes from 'eclient' branch to eds' master branch. > This will be part of evolution-data-server 3.1.2. > > I'll adapt evolution-exchange, evolution-mapi, evolution-groupwise and > evolution-couchdb for the API and "opening phase" changes. Feel free to > poke me if you've any questions.
Red Hat conscripted me into adding Evolution integration for the new GNOME Online Accounts service debuting in GNOME 3.2. The plan is to support Google accounts configured through GOA in Evolution 3.2. This is slowing down my progress on the account-mgmt branch and putting it at greater risk of not being ready in time for 3.2. The changes in that branch are too invasive to merge at the tail-end of a devel cycle, so I need to finish it up soon or I'll have to punt to 3.3. Since merging the account-mgmt branch will change nearly all client-side APIs in E-D-S including EClient, and since it would be wise regardless of my schedule to allow ourselves some extra time to tweak this brand new EClient API before pronouncing it frozen, what do you think about forcing users of it to acknowledge that the API is still unstable by having them do something like: #define ECLIENT_API_IS_SUBJECT_TO_CHANGE #include <libecal/e-cal-client.h> and leave that requirement in place until 3.4 or maybe even 3.6? This seems to be the de facto standard way among GNOME libraries of indicating that an API is still unstable in a stable release. Of course once we release 3.2 the usual rules apply to the gnome-3-2 branch; we can only make further changes to the API in 3.3. Sound reasonable? _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers