Re: PECL versioning

Hi Steph, On Wed, Mar 19, 2008 at 10:07 PM, Steph Fox <steph@zend.com> wrote: > Hi all, > > I've been looking into the existing PECL setup, preparing the way for > putting package release DLLs on pecl.php.net. Important sidenote, have you noticed our proposal for the current summer of code? It is only an idea, there is thoughts and projects behind this proposal. We even have a box to build DLLs on demand. Can I suggest to document our thoughts in a dedicated section in the wiki? And even more important to a) prioritize and b) define who's doing what/when. It will help to waste our precious time to make the work twice :) > 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, There is only one safe way, the package version. The other informations (either in the various headers or the rc) are rarely updated or even used. > 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. I can image imagine to add -dev to tell the users that he is using a snapshot, like what pecl4win provides now. > 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. It can be in both places. But one would better have to define it in the headers and use the definition in the source files (like in MINFO, or foo_version()). > 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... The version in the package.xml for the release you are using should be the reference. If the sources code contains the correct placeholders, they will also used the right version number (using the replace option in the package.xml). The only problem is for the snapshots, which version-dev should we use? My plan was to let the developers define which branch matches which version (like MYEXT_1_8 for 1.8-dev for example). It should be also possible to let the developers define which branch should be used for which php versions for the snapshots. The releases build will use the information provided in the package.xml. > 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. We need them for the DLLs info, if we want to provide them. Other places have to be used as well, both for the build time or to be used at runtime by the end users (phpinfo, ext_version(), etc.). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org