We should change that to be of something more meaning full, maybe even
with a link to the matching PECL/PEAR entry rather then leaving the user
in doubt if he/she can actually make use of the function in his/her
environment.
Steps we need to take to better handle PECL extensions:
- Move PECL extension docs from peardoc to PHPdoc (split as needed)
This might be a bit of a problem as some extensions where moved to PECL
but previously where part of the core. This might be a bit of a
confusion for the user... Telling a user he has to install this
extension from PECL even though for his version of PHP its still shiped
within the default distribution might be even more confusing...
The docteam will be able to care about documenting exceptions if an extension was part of the distribution before...
- Hartmut's function list script collection should be extended
to handle PECL extensions and PECL version numbers, since this
script collection generates the version information you have
problems with. The most complicated part will probably be
the handling of bundled extensions, since corresponding PECL
/ PHP version numbers need to be known...
Is that really an issue? I can see the point in knowing the version
which came with the a php release, but for a function itself, the only
important information is the version of the extension. Since a
PECL-Extension can be updated regardless if there used to be a bundled
one, i don't see that as a really big problem. It's rather a nice to
know thing imho.
Think about *windows users*: if you set up PHP 5 on windows, it will not help you if you see on the Tidy documentation page that some functions are useable in version 1.1. Hey, you have just installed PHP 5... You would like to know if you can use it with the PHP you installed or not...
Goba