PECL versioning

Hi all, I've been looking into the existing PECL setup, preparing the way for putting package release DLLs on pecl.php.net. One of the things I've done (but not yet committed) is reworked the template.rc file in the PHP core. For those that don't know, this file generates package information that is stored in the library itself. Some of that info (description and version) is directly visible under Windows when the folder is switched to icon, tile or thumbnail view. The whole lot can be viewed regardless of folder settings by right-clicking on the DLL and choosing 'Properties'. There are separate fields for information about the current file and information about the 'product' to which the file belongs; in our case, the 'product' is PHP. So we can have the version of both the PECL package and the PHP binary it was built against, stored in the extension DLL. At present, all we have is data for PHP itself repeated twice over, and here's why: There is nowhere consistent to pick up current versioning information in PECL packages, only the last full package release in package.xml, and sometimes (as in Phar!) even that's wrong. Hardly any PECL packages have '-dev' anywhere, and a number of them have no version information at all. Those that do, don't have a standard home for it! Some declare the extension version in source files rather than headers, and some use *_internal.h or *_globals.h. I need to be able to tell the difference between something at the point of release and something under development, otherwise this project will be manual forever... One possible option would be to distribute a template.rc for every PECL package, since local .rc files override the main project .rc file. However, this - and all the other solutions I can think of that involve adding a new file across the board - would mean all PECL developers need to keep the version information in it up to date, regardless of whether they're already doing so somewhere among the package headers like good people. The template.rc approach is also platform-specific of course, so that's a less than brilliant solution. Suggestions welcome, - Steph