On Thu, 2011-06-09 at 07:12 -0400, Matthew Barnes wrote: > 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?
Hi, I hope not, I'm currently working on evo bits to be buildable with E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is done, but I'm postponing it till I have evo and the standard rest done as well). Having one API deprecated and second "unstable" doesn't sound good to me, same as there doesn't seem to be many things to change anyway. We can always increase .so name version, that's just for it, isn't it? Bye, Milan _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers