Re: PECL versioning

From: Date: Wed, 19 Mar 2008 21:42:56 +0000
Subject: Re: PECL versioning
References: 1 2  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-5178@lists.php.net to get a copy of this message
Hi Pierre,
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.
No I haven't, but I have asked Wez for access to the build box at omniti. (I presume you're talking about the same one?) Where's the proposal?
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 :)
Sorry, I thought announcing it on the internals list and in IRC was probably enough - evidently not so :)
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.
That's... not safe either. It's where I'd pick up info for releases, sure, but it's not safe info for pecl4win/snaps.
I can image imagine to add -dev to tell the users that he is using a snapshot, like what pecl4win provides now.
pecl4win doesn't actually provide that at all. That's one of the problems I'm trying to fix :)
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()).
But how do we solve that problem for 215 packages? I did think of putting something in the coding standards, but it's a bit too late for all of them.
The version in the package.xml for the release you are using should be the reference.
Yes, for releases. Again, not for snaps. You probably misunderstood what I'm saying - if I change the template.rc in the core it will affect both. 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.
I'm not worried about branches for now - that's Edin's department, or possible the GSoC department. My only concern is that the information embedded in a PECL release DLL is correct.
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.).
Good point. - Steph
Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php


« previous php.pecl.dev (#5178) next »