(I cannot Ctrl+L the message)

On Thu, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote:
> On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: 
> > I hope not, I'm currently working on evo bits to be buildable with
> > 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?
> Anything in the EClient API dealing with ESourceList, URI strings, or
> default sources will be removed when the account-mgmt branch is merged,
> and there's a fair chance now that may not happen until 3.3.  So the API
> is unstable whether we claim it to be or not.
> Obviously we would bump sonames when things change with or without the
> #define.  My suggestion was more about setting expectations for users of
> the API.  It's a way of saying "we think this API is stable but it's
> still too soon to know for sure; fair warning".

It's different, from my point of view, as it's only few functions, with
compare of the whole EClient related API, not talking that it's trying
to be compatible, in this account management area, with the previous
API, where your change just changes core functions. Thus I would keep
this as is.

By the way, thinking of your announcement, I hope you are fine if I'll
finish this "stop using deprecated Book/Cal API in evo" as soon as
possible and commit it, thus it'll have more testing (I'm pretty sure
I'll introduce few regressions and bugs, even it's more or less monkey
work). As I mentioned couple times on various threads, messages and
maybe also IRC chats, this will make your life pretty harder, as the
change will not be simple, and the initial merge of such change into
your account management branch will be painful.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to