Re: [Evolution-hackers] New 'eclient' branch in eds

[Matthew Barnes <mbarnes redhat com>]

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?