No worries, we're not on a strict release schedule. We can do point
releases at any time if you find that something needs to be updated.
Thanks for your continued involvement. We're really looking forward to
the final outcome.
-- Art
Chenthill wrote:
I was not able to try the upstream l
I have applied Chenthill's memory management patches (only to the
'libical' directory and to the examples -- still have to do the
'libicalcap' and 'libicalss' directories) using function names ending in
"_r".
IMHO, HANDLE_LIBICAL_MEMORY can be removed.
Ok folks, it's done ...
The rema
Since we do really want to remove the fork and pick up packages from
upstream, I can change the apis in evolution related packages if a new
set of apis with some suffix is provided from libical upstream.
Many of you have probably already read this on the libical mailing list,
but just in cas
Patrick Ohly wrote:
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 co
Chenthill wrote:
So it is better to inform all the stake holders about the change and let
them depend on the library versions to decide whether to free the memory
or not if they have a need to depend on the older versions of libical. I
think no one deny to make the necessary changes knowing that
Patrick Ohly wrote:
In the upstream libical certain functions return char * pointers into
memory stored in ring buffers. The caller must not free those pointers.
The drawback is that the life time of those strings is not predictable.
In the current Evolution libical, those same functions (not re
Chenthill wrote:
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
Hello!
http://sourceforge.net/projects/freeassociation/ has released 0.32 of
libical on 2008-09-01. The KDE-PIM team has switched to that code for
KDE 4.2.
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote
