Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

[Patrick Ohly <Patrick Ohly gmx de>]

On Wed, 2008-09-10 at 08:18 -0400, dothebart wrote:
> Since it doesn't make sense imho to mix old style and new style api
> calls in one application imho, and I hink we can deprecate the old
> style.

We can deprecate it, but as you said yourself earlier, moving all
developers over to the new API at once might not be possible, so the old
one should stay around for a while.
> 
> It also should be exeptable to drop binary compatibility; raise the
> lib-version, and add one significant incompatible function here, which
> gets triggered, so distributors have to recompile applications.

Please try to avoid breaking backwards compatibility. I release
SyncEvolution binaries and already have to compile three different
versions just because of ABI changes; changing the libical ABI would add
another version :-/

> I think the oldstyle methods realy should just be wrappers in the
> headers, and I like the idea of hiding them via an define.

Just to be clear, my proposal was to have them as normal functions under
the old names (for backwards compatibility). They could be hidden by
defines, but I don't like that because then someone reading code which
calls libical cannot tell whether the code handles the memory correctly
unless he also checks how it is compiled.

Cut-and-paste could lead to memory handling errors.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/