Re: [Evolution-hackers] Retiring evolution-exchange
On Fri, 2012-06-01 at 15:48 -0400, Matthew Barnes wrote: > The backend-facing APIs less so. They tend to see more churn anyway, > even without my branch. I can't think of a recent release where the > backend APIs didn't change a little. And that's fine -- the damage is > contained -- but we still have to go touch all the backends for every > API change and some of those aren't trivial. And especially with this > new E-D-S architecture I've cooked up, which is an improvement but > still far from perfect, I think we'll be seeing a rash of backend API > changes over the next few devel cycles. So I'm not really buying the > "toy" argument. Hi, OK, I suppose we can always reincarnate it when there will be enough user demand on it. The last backend API changes seemed to me as not that complicated, at least those I helped with (on review and backend adaptation parts), kind of monkey work there, but I agree that some changes can be harder to test. What about a "compromise", drop support for evolution-exchange when 3.7.x development begins? I suppose it'll be fair to have the main API changes done and any potential community person taking care of it will not need to learn all the hard changes being done during 3.5.x, thus it'll be lighter start for him/her/them. Bye, Milan ___ 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 > >#include > >#include > >#include > >#include > > 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 directly is deprecated. >#warning Please use #include 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
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
