On Wed, 12 Nov 2008, Lukas Kahwe Smith wrote: > 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/mhash
yes, yes > 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 no > 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 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be > no external dependencies in this case no, no > 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. > > 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 a - definitely not b - there is not enough test cases, and there are way too many changes to see what was changed. From what I can see now, allowing this enormous big patch into HEAD was also a bad idea. (And seriously, this shouldn't have been on your list IMO). Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php