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

[Patrick Ohly <Patrick Ohly gmx de>]

Hello!

A while ago in this thread I argued in favor of keeping the old
functions around with their old semantic to preserve backwards
compatibility. I still stand by that logic for *libical* users.

But later it occurred to me that for *libecal* users this is an API
change because code which was compiled against the latest libecal may
free the memory and therefore crash when the libical implementation is
no longer the one from libecal, but the upstream version.

Therefore the revision will have to be bumped from
        LIBECAL_CURRENT=9
        LIBECAL_REVISION=1
        LIBECAL_AGE=2
to
        LIBECAL_CURRENT=10
        LIBECAL_REVISION=0
        LIBECAL_AGE=0

SyncEvolution would remain binary compatible *without* a revision change
because it checks at runtime how memory handling is to be done. *With*
the revision change I'll have to compile another version of it :-/

But there might be other users of the library which don't check at
runtime (Evolution itself for example) and therefore it is safer to bump
the revision. I'd be more than happy to hear that I'm too concerned here
and that the revision change won't be necessary.

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