> > > I don't want GIF support in ;-) > > > > > While I appreciate your reasons for not wanting GIF and agree with them on > > an academic level, I don't think it makes sense from our user's perspective > > to hold back support for something for which the base code already exists > > and requires only a small amount of administrative front-end work. > > Although I don't like GIF, that was not really the reason for saying it. > I meant that delaying PHP 5 because of GIF is stupid. > Ah, my misinterpretation then, sound like we agree on not doing GIF in 5.0.0 and keeping the release date as is.
> Yeah, it's prolly ok to put it in 5.0.1, as long as that's QA-ed > and handled the 'normal' way, like Ilia is doing for 4.3.x. Don't screw > up or change our release things for the silly GIF stuff. > Ah, I wasn't aware the PHP_4_3 branch would get an updated libgd. That sounds like a good thing though, it'll reduce the pressure to upgrade to PHP5, and as a parallel discussion noted: migration is not a trivial act to be taken lightly. > > In any event, users have the option of using the GD library directly from > > boutell.com at any time from the moment the author releases it. The PHP > > release doesn't need to bundle it for it to work. > > But the GD lib from Boutell misses a lot of our fixes though. > True 'nuff... I wonder, does it make sense to release a "PHPized" version of libgd alone so that people who (for their own internal reasons) can continue to use older versions of PHP without upgrading, but can replace their GD extension with a GIF enabled one? It seems a little silly since it makes more sense (from my perspective) to simply upgrade to 4.3.8 (I'm assuming this is the version that'll have the new libgd), but those that use distro packages tend to ride several versions behind because of their distros vetting process. Hopefully those making the packages have enough sense to extract the PHPized libgd from CVS or a recent release, but giving them a little help in that respect couldn't hurt. Then again, who are we to be maintaining/releasing someone else's lib? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
