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
