Hello, this is kind of heads-up e-mail about upcoming API changes in evolution-data-server. I also do not like them, but they are sometimes necessary.
The first part is about porting the calendar to use libical-glib [1], instead of libical, in order to finally provide introspection for it. The change was so huge that it deserved an API bump from 1.2 to 2.0 (libecal-1.2 and libedata-cal-1.2 will become libecal-2.0 and libedata-cal-2.0). The API around ECalComponent and its structures had been made introspection friendly too. I took the opportunity and removed all the deprecated and obsolete stuff from libecal and libedata-cal. This work depends on the unreleased libical git master, but there's planned a 3.0.5 release of it with the necessary changes. The second part was about preparation for passing flags from the client towards the backend to influence behavior. It was initially meant for this issue [2], but I extended it to pass also information about conflict resolution for write operations. This change touched all the APIs - the client side API, the server side API and the D-Bus API. The last is probably the most disturbing, at least in case of the Flatpak applications, which build against some version of the evolution-data- server, but rely on the host system evolution-data-server (it's possibly broken on both sides, aka building with new eds, but run with old, or build with old eds, but run with new). I'd say the best option for such applications is to run the eds services inside the Flatpak sandbox, which has the advantage that also the server side fixes are included in the application, not only the client side fixes. It has a downside, the downloaded data and configurations are not shared with the system. I guess it's a downside of Flatpak in general, but that's only my opinion. I made the same changes (for the [2]) for libebook, libebook-contacts and libedata-book, where I also changed some defines (added E_ prefix) and dropped EDataBookStatus error enum, which had not been really needed (similarly as I dropped EDataCalCallStatus). It could be replaced with EClientError and EBookClientError. As with the calendar, this touched the D-Bus API too. These book changes are quite straightforward. All the changes are prepared in this side branch: https://gitlab.gnome.org/GNOME/evolution-data-server/tree/wip/mcrha/libical-glib The 'make check' passes without errors. I already have prepared evolution, evolution-ews and evolution-mapi, though only as a buildable. The testing is to-be -done, I only didn't want to block this due to these three projects. Looking into the other API users, I found these hosted on GNOME: almanah bijiben california ekiga evolution-activesync folks glabels gnome-calendar gnome-contacts gnome-phone-manager gnome-shell gnome-todo I plan to create 'wip/mcrha/eds-libical-glib' branches in each and help with porting as much as I can. The idea is that the maintainers will just merge the branch changes and it'll be all (from the coding point of view). I know the branch name is inaccurate for the book changes, but I decided to keep all these things in one branch for simplicity. I believe it's better to break the API in a single release, instead of doing that within multiple releases. It will make it easier for the maintainers of the applications - the porting effort will be done only once, not multiple times. I have in my list these additional projects (to be verified whether any changes are needed there and help with them if yes): elementary-calendar ffgtk libopensync-plugin-evolution2 libreoffice pidgin-chime sflphone syncevolution wingpanel-indicator-datetime If you know more, then feel free to let me know. I'll be happy to help with the porting. With respect of timing, my plan was to have the things prepared for 3.35.1, I expected that the changes will take longer, but it went quite smoothly (well, actual testing will take some more time). I definitely want to wait for an official release of libical 3.0.5 with the necessary changes in its libical-glib part. Then we can decide, depending in what state respective projects will be. Maybe it'll be possible for 3.33.2 or shortly after it. I definitely do not want to push this close to the end of the development phase, I'd rather do this in the beginning of it, thus any third-party projects have enough time for porting. That's another reason why I chose 3.35.1 initially. I know this change will break some GNOME infrastructure, like the GNOME Continuous effort, thus it's understandable to have the critical projects prepared/ported first and commit the things (almost) at the same time. This would need some coordination, which is another reason for this e-mail. I do not foresee any additional API changes currently, definitely not on the D-Bus side, thus once this is done, the API should stay stable for the next several years, I believe. Of course, everything depends on the feature requests and similar needs, but from the past experience it seems it will be fine. Bye, Milan [1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 [2] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/59 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers