Re: [Evolution-hackers] libecal and libedata-cal versions

[Harish Krishnaswamy <kharish novell com>]

On Mon, 2006-07-31 at 17:05 +0200, �stein Gisn�wrote:
> When the version bump was commited to 2.6.x, it was not commited to
> the 2.7.x tree. Why was that? Because you only bump versions just
> before releases? I hope so. I noticed that libedata-cal versions were
> synced with 2.6.x in
> http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.184&r2=1.185.
> libecal was also bumped there, but "AGE" was not reset.
> 
> Is the plan to reset "AGE" just before the final 2.8.0 release, or was
> it a mistake not to reset it before. The last thing we want is to
> release 2.8.0 with a lower SONAME version than 2.6.x..

Hi �stein,

The recent libtool number bumps on libecal and libedata-cal do not map
to the corrective bump on 2.6.x (related to the recurrence changes).

<slight digression>

The changes pertain to the following (yet another ?) break on
libedata-cal

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h?r1=1.16&r2=1.17

that splits the calendar cache based on the component types. This change
was introduced to address a host of serious performance woes wrt to
remote servers that manipulate events, tasks and journals together.
You can find the details in my ChangeLog at

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h


This also involved adding an introspective function to e-cal.h
http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libecal/e-cal.h?r1=1.30&r2=1.31.


</slight digression>

You are correct in pointing out that if this is left unchanged would
lead to a dubious condition where the later release ends up with a
SONAME version lesser than the previous stable branch.

I intend to set it right during the final release (both ecal and
edata-cal libraries need a correction) along with the camel lib bits.

Hope you can help me with some review on these proposed changes as well.

Thanks,
Harish