Re: Re: cvs: php4 /ext/curl config.m4

At 05:44 PM 11/9/2002 +0100, Sterling Hughes wrote:

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, Maybe a good solution is for you to check if 7.10.1 works? If it does then it'll be easy to end this thread :) Andi