Hello,
next week's 3.33.2 release of evolution-data-server, on 2019-05-20,
will contain soname version bumps in libecal, libedata-cal, libebook
and libedata-book. At least unless anything bad happens.
The main change on the calendar part is that there will be used
libical-glib instead of libical, which allows automatic gobject
introspection generation. That turned to be as significant change as it
worth the calendar API change from version 1.2 to 2.0.
The other change on the address book and the calendar parts was about
adding a new argument into some methods, which touches both the C API
and the D-Bus API, thus there is a version bump on the D-Bus service
names as well. [1]
Below is the list of affected packages in Fedora, divided into four
sections:
* Those, which require patching:
almanah
bijiben (aka gnome-notes)
evolution
evolution-ews
evolution-mapi
folks
gnome-calendar
gnome-shell
gnome-todo
libopensync
libreoffice
pidgin-chime
syncevolution
* Those, which require only rebuild:
ekiga
evolution-rspam
evolution-rss
glabels
gnome-contacts
gnome-phone-manager
sflphone
* Those, which require patching, but are already retired:
california
ffgtk
* Those, which require work:
elementary-calendar
wingpanel-indicator-datetime
Any existing patches can be found through [3], which contains also
links to respective merge requests and bugs, filled to let know the
maintainers beforehand.
I will rebuild/apply patches to the packages I've commit rights for.
I'd need help with others. Especially those two elementary-related
packages won't work easily, because they use vala bindings, which they
bundle in the sources, thus there is needed a lot of work. One of the
elementary developers promised me to look on it once the eds is
released.
If you find more packages to be ported and you'd like to help with it,
just let me know.
Bye,
Milan
[1] This may cause trouble to Flatpak applications, which compile
against some version of the evolution-data-server (eds) and then
rely on the host system eds D-Bus services (that applies both
ways, it won't help to compile against older eds, because the
Flatpak application won't work on systems with the new eds). Such
applications can run their own eds services, as shown here [2].
The advantage of it is to receive also backend-specific fixes in
their Flatpak application, not only client-side fixes. The
disadvantage is that the data won't be shared between the
applications.
[2]
https://gitlab.gnome.org/GNOME/evolution/blob/master/flatpak/org.gnome.Evolution-stable.json#L258
[3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
