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 -- [EMAIL PROTECTED] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers