Re: [Evolution-hackers] What GLib and GTK+ versions do we support?
On Wed, 2006-09-20 at 21:09 +0530, Harish Krishnaswamy wrote: > 'Whatever GNOME 2.16 supports' was my top-of-the-head answer, assuming > few (if any) users might want to update to the latest Evolution > stand-alone keeping their GNOME desktops intact. This was my thinking > when I approved the patches. > > On second thoughts, there are users who use Evolution (for > Exchange/GroupWise connectivity) but run on a KDE desktop and it is not > all fun for them to update glib and above. > I feel it is more prudent to make the patch use g_slice features if a > supported version was available but falls back to the old implementation > otherwise. > > This adds to the maintenance foo but gets us a few more happy users. > > Any thoughts, others ? Perhaps lag behind the latest stable GNOME release for stable Evolution releases, so that e.g. evolution-2.8.x still compiles and runs fine on GNOME 2.14. But then evolution-2.9.x can utilize whatever new features GNOME 2.16 has to offer. Whatever policy is decided, configure.in should clearly state and check for the required versions of the libraries we depend on. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What GLib and GTK+ versions do we support?
Harish already knows my thoughts. :) Fallback code is always appreciated, because some of us are limited in what we can deploy because of support contracts. We aren't able to install the latest libraries because of these contracts. Also, version checking is appreciated during ./configure time. Evolution currently doesn't check for certain package versions and gladly builds for 20 minutes before failing on code that cannot compile on older versions of GTK and Glib. Dave >>> Harish Krishnaswamy <[EMAIL PROTECTED]> 09/20/06 11:39 AM >>> On Thu, 2006-09-14 at 16:26 -0400, Matthew Barnes wrote: > Stupid question maybe, but configure.in doesn't tell me. > > I'm asking because I'd like to use some recently added features like the > GSlice allocator in some patches I'm working o > n. What's the policy on > this? Use whatever GNOME 2.16 supports? 'Whatever GNOME 2.16 supports' was my top-of-the-head answer, assuming few (if any) users might want to update to the latest Evolution stand-alone keeping their GNOME desktops intact. This was my thinking when I approved the patches. On second thoughts, there are users who use Evolution (for Exchange/GroupWise connectivity) but run on a KDE desktop and it is not all fun for them to update glib and above. I feel it is more prudent to make the patch use g_slice features if a supported version was available but falls back to the old implementation otherwise. This adds to the maintenance foo but gets us a few more happy users. Any thoughts, others ? -Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers Disclaimer: According to Florida Public Records Law, email correspondence to and from the City of Largo, including email addresses and other personal information, is public record and must be made available to the public and media upon request, unless otherwise exempt by the Public Records Law. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What GLib and GTK+ versions do we support?
On Thu, 2006-09-14 at 16:26 -0400, Matthew Barnes wrote: > Stupid question maybe, but configure.in doesn't tell me. > > I'm asking because I'd like to use some recently added features like the > GSlice allocator in some patches I'm working o > n. What's the policy on > this? Use whatever GNOME 2.16 supports? 'Whatever GNOME 2.16 supports' was my top-of-the-head answer, assuming few (if any) users might want to update to the latest Evolution stand-alone keeping their GNOME desktops intact. This was my thinking when I approved the patches. On second thoughts, there are users who use Evolution (for Exchange/GroupWise connectivity) but run on a KDE desktop and it is not all fun for them to update glib and above. I feel it is more prudent to make the patch use g_slice features if a supported version was available but falls back to the old implementation otherwise. This adds to the maintenance foo but gets us a few more happy users. Any thoughts, others ? -Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
