Re: Re: cvs: php4(PHP_4_0_5)/sapi/fastcgi
| From: | Zeev Suraski | Date: | Thu, 22 Mar 2001 12:27:34 +0000 |
| Subject: | Re: Re: cvs: php4(PHP_4_0_5)/sapi/fastcgi | ||
| References: | 1 2 3 4 5 6 | Groups: | php.dev php.qa |
| Request: | Send a blank email to php-dev+get-49726@lists.php.net to get a copy of this message | ||
At 12:14 22/3/2001, Ron Chmara wrote:
1. Adding new/experimental extensions _can_ invisibly bug the rest of a build, if they require such nastiness as the recent pthread debugging. It's not only a minor configure issue when a built app breaks due to library issues, because extensions can be linked in conflicting ways. It does happen, it has happened.... in rather annoying, small ways (see mod_ssl vs. mysql client and -lpthread linking issues.). These bugs suck, but they do happen, because extensions are not ever totally isolated if they are running on the same system, and linking to something else.A new module that *is not enabled* would have to go through a lot of efforts in order to break the build. Of course, if you enable it, you're on your own, much like you're on your own with any experimental module. The risk of breaking *the stable* PHP parts is negligible. Right now, we knowingly ship PHP with large code portions which are not stable. We consider this ok, because these modules are considered experimental. Until this approach is changed, there's really no difference between adding new experimental modules during the RC process, or before it. That's why they're *modules*, and why PHP's modular. Everything else you said is fine, except it doesn't really apply to the issue at hand. Zeev