Hi,
Am Mittwoch, den 12.11.2008, 20:14 +0100 schrieb Lukas Kahwe Smith:
[...]
> 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
> II) remove ext/mhashyes, yes. Probably hack ZEND_FUNCTION(extension_loaded) to return true when "mhash" is passed and throw a deprecation warning. Is pretty easy but ugly. What would our ZE guys suggest to accomplish something like that? > 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 yes > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is c > 4) keep ext/phar enabled by default in 5.3? yes > 5) keep ext/sqlite3 enabled by default in 5.3? yes > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default yes > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case yes > 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. abstention > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 abstention cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
