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
