Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41875 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70306 invoked from network); 12 Nov 2008 19:54:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Nov 2008 19:54:51 -0000 X-Host-Fingerprint: 24.247.219.180 24-247-219-180.dhcp.cdwr.mi.charter.com Received: from [24.247.219.180] ([24.247.219.180:11377] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B3/92-07308-A843B194 for ; Wed, 12 Nov 2008 14:54:50 -0500 Message-ID: To: internals@lists.php.net Date: Wed, 12 Nov 2008 14:55:44 -0500 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org> In-Reply-To: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Posted-By: 24.247.219.180 Subject: Re: quick polls for 5.3 From: auroraeosrose@gmail.com (Elizabeth M Smith) [snip] > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing if > mhash is removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since > ext/ereg is more or less redundant with ext/preg and is likely to not > get much unicode love for PHP 6, the question is if we should mark it > with a E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > c) Document as is +1 (go ahead, let them shoot in foot) > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case +0 to both (don't care) > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things are > in HEAD and make it clear that they will be available for bug fixing and > BC issues resolving. the risk here is obviously that any BC issues will > be hard to isolate for end users. +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > b) MFH to 5.3 +1 Thanks, Elizabeth Smith