Marcus Boerger wrote:
Hello Lester,
Another major concern here since maintaining BC with *PHP4* is still an unfortunate current requirement in the field is what happens when PEAR actually uses namespace and other 5.3 only features. HOW will we manage accessing versions of PEAR that are compatible with our active codebase and so
ensure that we have compatible sets of packages?

PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4
then we cannot support PEAR either. Anyway, as far as I know PEAR does a
good job in maintenance, especially in supporting both PHP 4 and 5. And
some people are working on a new system that supports PHP 5.

Marcus - I've never USED PHP4 in production, but it will be some time before it has been replaced on a lot of ISP's so at present OUR users require maintaining support for PHP on the only versions they have available - at present. NOW it at least practical to freeze a version that supports PHP4 and all the 'extras' that are compatible with that version and not allow any new features to be included in that build. SO we do not have to test changes to the code base for PHP5.3 against PHP4. There have always been problems with using 'new' features but making them available to older versions, which the compatibility libraries provide, but it is looking as if 'Built for PHP5.3' will mean 'will not work on PHP5.2' much more so than previous 'minor version changes'?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to