ABI incompatibility after changing calendar ids to ECalComponentId

I've found some changes in header files in libedata-cal and libcal
between 1.4.2 and 2.6. It seems like some functions now have
ECalComponentId as argument type instead of GList to fix #266144,
#317575. The problematic change for libedata-cal is [1], [2], and [3].
Libcal is affected by [4].

Telling from the CVS log, it seems like the changes have been reverted
due to API changes, but then reapplied later. To me, it looks like the
changes break ABI compatibility, but LIBECAL_AGE and LIBEDATACAL_AGE was
never reset. Is there a reason why these two libraries keep their SONAME
through these changes? If not, I'm afraid I'll have to change the SONAME
in the Debian packages.

Thanks,
Øystein Gisnås

[1] http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-data-cal-view.h?r1=1.7&r2=1.8
[2] http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend.h?r1=1.16&r2=1.17
[3] http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-data-cal.h?r1=1.13&r2=1.14
[4] http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libecal/e-cal.h?r1=1.28&r2=1.29

_______________________________________________
Evolution-hackers mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/evolution-hackers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEVZM3g5e8AcS6nh0RAsAPAJsEGKRz2G7zaz20emOnDlqSM3wd5gCeIRTh
YjNFkHoYqBd1pa0JgjurjIQ=
=wkb1
-----END PGP SIGNATURE-----