> On Sat, 9 Nov 2002, Sterling Hughes wrote: > > >> On Sat, 9 Nov 2002, Sterling Hughes wrote: > >> > >> >> > >> >> There is no such release of Curl yet. This makes testing > >> >> the RCs quite a hassle now so either you revert those changes > >> >> or get the curl folks to release this 7.10.2. > >> >> > >> >> --Jani > >> >> > >> > > >> >7.10.2-pre4 is currently out, it should be released quite soon. > >> > >> But it's not 7.10.2 release. Revert the changes. > >> Or I will. > >> > > > >err... no. > > > >7.10.2 will be out long before PHP 4.3. We haven't even had the first > >RC for PHP, and its a lot longer before PHP releases to come out. If > >you want to test it for QA purposes, you can easily install one of the > >prereleases. 7.10.1 might also work, not sure.... > > You're now missing the point here. I'm NOT doing QA for Curl. > I'm not going to install ANY curl pre-release here. > > You can (if you wouldn't be so lazy) add some ifdef's around > the new stuff instead of everytime requiring people to update curl!!
Its not laziness... I'm not having that many '#ifdef's in the code. Some cases it makes sense for cURL to have #ifdef's, in some cases it'll just make the code both unreadable and unmaintainable. The solution I'm working on is to autogenerate from the curl.h and multi.h files. However, that's after i get the multi interface in, and the cURL extension is hopefully up-to-date. Anyhow, I get the point. I just don't find it valid, if you're doing QA, than upgrading to a pre-release is not that much harder than upgrading to the release itself. PHP-Curl is _not_ that often tested in the QA process, simply because most features rely on a server being available, and with PHP/QA there is none. Therefore, very few regression tests. -Sterling -- Sterling Hughes <[EMAIL PROTECTED]> Did I help you? Consider a gift: http://wishlist.edwardbear.org/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
