Re: [Evolution-hackers] libecal and libedata-cal versions
- From: Harish Krishnaswamy <kharish novell com>
- To: Øystein Gisnås <oystein gisnas net>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] libecal and libedata-cal versions
- Date: Wed, 02 Aug 2006 15:55:16 +0530
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
> 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..
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).
The changes pertain to the following (yet another ?) break on
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
This also involved adding an introspective function to e-cal.h
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.
] [Thread Prev