Summer of Code

[Luke Schierer]

Mark Doliner wrote:
> On Tue, 25 Mar 2008 13:55:04 -0400, John Bailey wrote
>> Mark Doliner wrote:
>>> On Tue, 25 Mar 2008 00:43:01 -0400, John Bailey wrote
>>>> I'm certainly not intending to suggest we completely ignore .NET 
>>>> simply because of these issues, but MFC does gain us the advantage 
>>>> of working on Windows NT 4.0, Windows 98, and Windows ME
>>> I don't think we should worry very much about supporting operating systems
>>> that have been obsolete for over 6 years, and not supported by Microsoft for 2
>>> years.
>> By that same token, GTK+ 2.0.x was last released on 2002-11-20 and 
>> has gone unsupported by its developers for quite some time.  GTK+ 
>> 2.2.x was last released on 2003-09-04 and GTK+ 2.4.x was last 
>> released on 2004-10-12.  Both of these have also been unsupported by 
>> the developers for quite some time.  All of these GTK+ releases are 
>> obsolete, yet we still support them, when supporting them gains us 
>> little except more of a mess of preprocessor directives in our code 
>> to disable or work around things that don't work with these older 
>> GTK+ versions.
>>
>> If we're going to actively ignore supporting a product (whose 
>> support would come mostly for free by using compilers that are 
>> readily available, such as mingw, and not going overboard to add 
>> crazy stupid stuff like the official IM clients do) simply because 
>> the developers no longer support it, then we should drop support for 
>> anything older than GTK+ 2.6.0 (which I have stated my desire for on 
>> numerous occasions), and more likely 2.8.0.
> 
> I'm in favor of dropping support for GTK+ older than 2.6.0, and more likely 2.8.0.
> 
> -Mark

how old a gtk is redhat supporting? For what sort of timeline at this point?

luke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080325/eb1743fe/attachment.sig>