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

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..

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

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

</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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]