Re: [Evolution-hackers] Merging the account-mgmt branch this weekend
On Thu, 2012-05-31 at 12:39 -0400, Matthew Barnes wrote: This is a heads up that I will be releasing Evolution 3.5.2 and co. this weekend and then merging the account-mgmt branches for E-D-S, Evolution, and Evolution-EWS. Evolution-MAPI will follow sometime after the merge. The account-mgmt branch is now merged for 3.5.3. For the inevitable flurry of bug reports which will now commence, if you could please tag them with evolution[account-mgmt], that would help me track them more easily and respond faster. Current status is EWS is ~90% done. It's functional, just a few loose ends to wrap up. My priority for this week will be submitting patches to affected projects to help them adapt to the API breaks, and also deal with whatever critical issues you guys find. Once the major regressions are under control, I'll start in on MAPI. With any luck I'll have MAPI ready by 3.5.3. I'll get to the other groupware backends in due time. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Front-end header files for E-D-S libraries
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: For 3.1, I would like to provide a top-level header file for each of the libraries in E-D-S and deprecate including individual header files. The benefits should be clear by now: more flexibility to change or rearrange header files without breaking the public API. Valid #include directives for E-D-S libraries will be: #include libebackend/libebackend.h #include libedataserver/libedataserver.h #include libedataserverui/libedataserverui.h #include libebook/libebook.h #include libecal/libecal.h I'm not bothering with the backend libraries just yet. They're less of an issue than the client-side libraries. To enforce this we'll use the same mechanism as in GLib and GTK+, except for now we'll issue a #warning instead of an #error: #warning Including libecal/e-cal.h directly is deprecated. #warning Please use #include libecal/libecal.h instead. We could also test for an EDS_DISABLE_SINGLE_INCLUDES definition which would issue an #error instead of a #warning. After maybe a year or two we'll crack down and issue #errors in some future 3.(odd).1 release. Since I've already broken E-D-S APIs across the board for 3.5.3, I'm following up on this as well. Same plan as what I originally sketched out, except I'm skipping the deprecation phase and moving straight to #error since there's no point drawing this out, and I _am_ bothering with the backend libraries. It turns out to be nice for backends to just have one #include. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
