Proposed changes for Pidgin 2.7.0

[Warren Togami]

On 07/14/2009 06:05 PM, John Bailey wrote:
> Warren Togami wrote:
>> What reasons exactly make it necessary to drop older glib support? Are
>> the current workarounds onerous? An earlier discussion in #pidgin
>> indicated that pidgin-3.x during 2010 would be a good cut-off for
>> legacy versions of glib.
>
> Strictly speaking, it's not necessary. That said, many of us are tired
> of being limited to the API available in these old versions of both GTK+
> and glib.
>
> A perfect example is the Yahoo! protocol plugin changes in version
> 2.5.7, which would not build on RHEL4. We now have glib version checks
> in the code, but we have so many of these version checks with alternate
> code paths that it's hard to follow a number of functions. Moving to a
> minimum of GTK+ 2.10.0 and glib 2.12.0 will allow us to get rid of
> almost all of these version checks, thus significantly simplifying a
> number of functions.
>
> We also are shipping entire widgets from GTK+ (GtkComboBox, added in
> GTK+ 2.6.0) and libegg (the eggtrayicon thing added to GTK+ 2.10.0 as
> GtkStatusIcon) for no other reason than backward compatibility with old
> GTK+ versions. I didn't like this at the time (although at the time the
> eggtrayicon thing was essentially mandatory), and I like it even less now.
>
> We're additionally hindering third-party plugins such as the Facebook
> protocol plugin by continuing to support old versions. Technically these
> plugins can state their own requirements, but this makes their support
> that much more difficult when they have to tell their users that Pidgin
> and libpurple will work on a given system but the plugin will not.
>

This last argument regarding third-party plugins is valid, although this 
suggested minimum will not satisfy farsight2.

I am not suggesting forever supporting old versions of glib.  Whenever 
upstream decides for a break with legacy, the old release will remain at 
that old pidgin version.

Might we consider calling post-break 3.x?

Whatever the break point is called, could we have a critical bug-fix and 
security only branch of the pre-break?  Declare this branch supported 
until 2011, and occasionally do point releases for important reasons.

pidgin-2.6.0.1 (security and crash fixes)
pidgin-2.6.0.2 (security)
pidgin-2.6.0.3 (ICQ protocol broke again, backport fix)
pidgin-2.6.0.4 (DoS fix)
etc.

OTOH, if it turns out that we can build pidgin-2.7.0 on RHEL-4 with the 
parallel glib-2.12 without the glib version conflict issues, this is not 
necessary.  I don't think this is possible though.

Warren Togami
wtogami at redhat.com