About ProgressReport and msn-pecan

[Felipe Contreras]

2008/6/13 John Bailey <rekkanoryo at rekkanoryo.org>:
> Dossy Shiobara wrote:
>> On 2008.06.12, Gary Kramlich <grim at reaperworld.com> wrote:
>>> The problem is that pidgin/purple are compatible all the way back to
>>> glib 2.0.0 and iirc we currently supply packages for some distros that
>>> only support 2.0.0 (stu, correct me if I'm wrong here).
>>
>> This sounds like a really lame explanation.  Pidgin developers have no
>> qualms about making UI changes, but insist on supporting some severely
>> outdated dependency like GLib 2.0.0?
>
> We don't all insist on supporting the "stone age," so to speak, but even those
> of us that support forgetting about the older library versions realize that it
> will break things for some people.  We have debated the compatibility thing on
> more than one occasion, and we did finally come to a consensus to require glib
> 2.4.0 (I think, but it might have been 2.6.0) for 3.0.0.
>
> The problem here is that dropping support for older stuff too soon is a bad
> idea, and it's particularly difficult to know when "too soon" actually is.  For
> example, I know a good number of production environments still use RedHat Linux
> 9.0, even though RedHat no longer supports it.  I have seen first-hand a number
> of production environments that still use Windows 98, although it's been
> abandoned by Microsoft for years.  Windows NT 4.0 still has popularity even
> though it's been abandoned for years too.  (Note that compatibility with Windows
> 98, ME, and NT4.0 is why we still link against GTK+ and glib 2.6.x--anything
> newer doesn't work on these old operating systems).

When you think about it projects increase their dependencies when they
need something new. Why? Because there are bug-fixes, improvements, it
just makes everyone's life easier.

Also, it's a sign of respect to the GLib developers. What would you
think about Adium developers if they used a libpurple from 2002? Of
course, it's different, GLib *is* widely used.

Usually if some lame user can live with a library that is from 2002 he
can very well live with an old version of Pidgin.

You are worrying about a potential user that doesn't exist. If I was
using a stone age system, I would compile a new GLib on /opt/glib, and
export LD_LIBRARY_PATH=/opt/glib/lib; voilà.

Worrying about this potential user just makes everybody else's life
miserable because he doesn't know how to have two GLib's on his
system.

> And to directly address your comment about UI changes, note that we specifically
> include the source for the GTK+ widgets we need that are not present in GTK+
> 2.0.0.  UI changes don't mean we have to abandon compatibility.
>
> There *is* value in the logic of "if it ain't broke, don't fix it."

Of course, a GLib from 2002 isn't broken, that's why they never made
another release after that.

Actually msn-pecan needs some stuff from GLib 2.3.1, which was
released on 2003. Also, some stuff from 2.6.0, which was released on
2004.

We are supporting a library from 6 years ago without any valid reason?
This is madness.

Anyway, I just added support for GLib 2.0.0 in msn-pecan, and now it's
uglier, but I guess when you mess with libpurple that's what you are
looking for anyway.

-- 
Felipe Contreras