The proposed solution is to focus on "forward compatibility"
instead. PHP version 5 has a builtin means to ensure that code is forward
compatible, which is
E_STRICT error reporting level.
The package is considered
it can be used under PHP 5.1.4+
its files do not emit error messages when used with error
reporting level set to
E_ALL | E_STRICT under PHP
it follows PEAR coding standards that apply to PHP5-only packages
it has only
E_STRICT-compatible package may have optional
dependencies that are not
E_STRICT-compatible, but this
After this RFC is accepted, a deadline for accepting the new non
E_STRICT-compatible packages is set as January 1, 2007.
This deadline should be prominently announced on PEAR website and in
PEAR manual. All new PHP5-related coding
standards should also be integrated into the manual.
Developers wishing to propose a new non
E_STRICT-compatible package or start work on a non
E_STRICT-compatible new major version (as defined in
guidelines for BC breaking releases) of an existing package
should do so before the deadline.
After January 1, 2007 all new packages proposed via PEPr and all
new major versions of existing packages should be
E_STRICT-compatible. Proposals for non
E_STRICT-compatible packages that reach this deadline not
in "Called for votes" state should not be called for votes until the
package is reworked to be
the person proposing a new package may choose to also provide a
version of said package that can be run under PHP version 4. Such a
version requires a separate proposal that may only be called for votes
after the proposal of
E_STRICT-compatible version is
accepted. The package must have the name of
E_STRICT-compatible version with 'PHP4' appended (ex.:
if a package does not yet have
E_STRICT-compatible version then non
E_STRICT-compatible subpackages for it may be accepted
at the discretion of base package's developers. If base package
E_STRICT-compatible version then acceptance
of such subpackages falls under the previous exception.
Development and release process of existing PEAR packages which
E_STRICT-compatible may continue as usual. The
only new requirement is that if a new major version of a package is
started, it should be
If a new major version of an existing package was registered on PEAR website before the deadline is reached or the code of this new major version was present in PEAR SVN then this version is considered an "existing package" for the purpose of this RFC.
Nevertheless, developers of existing packages are strongly
encouraged to update their packages for
E_STRICT-compatibility if a BC break is still allowed by