Andi Gutmans wrote:
I agree, and we should currently have both so that we can migrate users to Derick's new code. Derick, I think you need to return the support for the old functionality (it can probably be done quite easily by taking the old code as-is). We should then have an INI option which selects between the two (I hate INIs but I don't see much of a way around it). To be realistic, considering the possible breakage in apps, I don't believe 5.1 can be released in the current state.
We should be able to run 5.1 on a 5.0 system and at worst get warnings - hidden potential differences are something to be avoided ;) Would it be possible to have dev snapshots of PHP6 on windows where *THIS* sort of thing can be played with in earnest and the migration notes worked out. ( Probably need those from both PHP4 and PHP5 :( ) I started playing with PHP5 well before it was finally released so never bothered with PHP4 in production. Having to try and maintain BC with PHP4 in OS projects is becoming a pain, and all these 'subtle changes' being applied to PHP5 and back ported to PHP4 are just adding unnecessary work. *PLEASE* can we have a *PROPER* freeze on some back porting and set a rule that once PHP6 is more accessible ( I NEED UNICODE ;) ) then nothing will be applied to PHP4 that requires any code changes and ideally PHP5 as well ? Hopefully the tidy UNICODE implementation in PHP6 will provide enough incentive for 4 and 5 to be sidelined? But we are probably going to need a 'code tidier' that identifies areas that need work in legacy code? -- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
